From owner-freebsd-net@FreeBSD.ORG Mon Apr 22 04:21:05 2013 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 03A5380E for ; Mon, 22 Apr 2013 04:21:05 +0000 (UTC) (envelope-from karl@denninger.net) Received: from fs.denninger.net (wsip-70-169-168-7.pn.at.cox.net [70.169.168.7]) by mx1.freebsd.org (Postfix) with ESMTP id C393F1F2E for ; Mon, 22 Apr 2013 04:21:03 +0000 (UTC) Received: from [192.168.1.40] (localhost [127.0.0.1]) by fs.denninger.net (8.14.6/8.13.1) with ESMTP id r3M4Kf95010525 for ; Sun, 21 Apr 2013 23:20:53 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sun Apr 21 23:20:53 2013 Message-ID: <5174BA94.7000907@denninger.net> Date: Sun, 21 Apr 2013 23:20:36 -0500 From: Karl Denninger User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 MIME-Version: 1.0 To: Steven Hartland Subject: Re: Odd NAT/IPSEC question -- help! :-) References: <517333A8.7020704@denninger.net> <394C5F1CA58741F9965A5782A1117153@multiplay.co.uk> <5173509A.905@denninger.net> <517364B3.9000403@denninger.net> In-Reply-To: <517364B3.9000403@denninger.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: freebsd-net@freebsd.org X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 04:21:05 -0000 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" >>> ... >>>> 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 ®/ Cuda Systems LLC