From owner-freebsd-net@FreeBSD.ORG Sun Apr 21 04:02:02 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 02FB61E1 for ; Sun, 21 Apr 2013 04:02:02 +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 BE7C8338 for ; Sun, 21 Apr 2013 04:02:01 +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 r3L420sL086701 for ; Sat, 20 Apr 2013 23:02:00 -0500 (CDT) (envelope-from karl@denninger.net) Received: from [192.168.1.40] (TLS/SSL) [192.168.1.40] by Spamblock-sys (LOCAL/AUTH); Sat Apr 20 23:02:00 2013 Message-ID: <517364B3.9000403@denninger.net> Date: Sat, 20 Apr 2013 23:01:55 -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> In-Reply-To: <5173509A.905@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: Sun, 21 Apr 2013 04:02:02 -0000 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. -- -- Karl Denninger /The Market Ticker ®/ Cuda Systems LLC