Odd NAT/IPSEC question -- help! :-)

[Karl Denninger]

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 at 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 at 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 at 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.

-- 
-- Karl Denninger
/The Market Ticker ®/ <http://market-ticker.org>
Cuda Systems LLC