Date: Sun, 21 Apr 2013 23:20:36 -0500 From: Karl Denninger <karl@denninger.net> To: Steven Hartland <killing@multiplay.co.uk> Cc: freebsd-net@freebsd.org Subject: Re: Odd NAT/IPSEC question -- help! :-) Message-ID: <5174BA94.7000907@denninger.net> In-Reply-To: <517364B3.9000403@denninger.net> References: <517333A8.7020704@denninger.net> <394C5F1CA58741F9965A5782A1117153@multiplay.co.uk> <5173509A.905@denninger.net> <517364B3.9000403@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 4/20/2013 11:01 PM, Karl Denninger wrote:
> On 4/20/2013 9:36 PM, Karl Denninger wrote:
>> I don't think so -- gre is not involved in the config.
>>
>> On 4/20/2013 7:59 PM, Steven Hartland wrote:
>>> ----- Original Message ----- From: "Karl Denninger" <karl@denninger.net>
>>> ...
>>>> My "ordinary" NAT entry is simply "nat 1 ip from any to any via em1",
>>>> which works fine for ordinary "on the client" traffic; no problems with
>>>> that.
>>> ...
>>>
>>> Just a stab in the dark, as I vaguely remember something similar, do you
>>> also need to configure your nat for gre as well as ip?
>>>
>>> Regards
>>> Steve
>>>
> I traced this down a bit further -- it's more odd than I thought.
>
> The packets are coming from the OTHER END'S native IP number! That's
> why I couldn't find them.
>
> If I point the DNS server at the external gateway IP in the strongswan
> config file I immediately start getting complaints in the logs, but
> they're coming from the external IP Address -- NOT THE TUNNEL ADDRESS.
> It looks like contrary to my previous expectations the tunnel address is
> pretty-much irrelevant, so long as it's not an address in use elsewhere
> (which implies I should use something like 10.x.x.x for it.)
>
> If I'm reading the IPSEC documentation on how tunnel mode works
> correctly this is what's supposed to happen -- the tunnel is a pure
> encapsulation+encryption; it is stripped and the original packet (which
> was encrypted) then decoded, and voila -- the packet appears exactly as
> if it was presented "raw" from the other end. So it appears it's
> working, but this is VERY different than what I'm used to seeing from
> PPTP/LT2P. This does not explain why I thought I had full access to
> the internal LAN -- it is rather clear now that I do not.
>
> In other words:
> [root@NewFS /usr/local/etc]# ipsec status
> Security Associations (1 up, 0 connecting):
> remote[1]: ESTABLISHED 16 minutes ago,
> 70.169.168.7[70.169.168.7]..._*208.54.35.246*_[karl@denninger.net]
> remote{1}: INSTALLED, TUNNEL, ESP in UDP SPIs: c2ecb09f_i ae9d3747_o
> remote{1}: 192.168.1.0/24 === 192.168.1.71/32
>
> The packets are coming from the underlined/bolded IP number once they're
> decoded and presented in the local system! What I'm getting in the log
> with the DNS IP defined as the external IP of the gateway machine is this:
>
> Apr 20 22:54:41 NewFS named[3775]: client 208.54.35.246#33784: query
> (cache) 'imap.gmail.com/A/IN' denied
>
> That won't work because the external address is configured to refuse to
> respond to anything other than known secondary DNS servers. But it
> explains where my packets are disappearing to -- they're being emitted
> from IPSEC on the gateway under the client's public IP number.
>
> I'm getting more confused rather than more enlightened here.... What I
> THOUGHT I should be seeing are packets, once decoded, coming from the
> tunnel IP.
>
> Nope.
Further update on this -- I got it.
StrongSwan is a bit confusing, but I got it figured out. I'll write it
up in the next few days once I condense it all down. Everything is
working in tunnel/transport mode and it's FAST.
--
-- Karl Denninger
/The Market Ticker ®/ <http://market-ticker.org>;
Cuda Systems LLC
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5174BA94.7000907>