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" <k...@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*_[k...@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 _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"