Date: Tue, 19 Nov 2002 14:52:25 -0500 From: Scott Ullrich <sullrich@CRE8.COM> To: 'Guido van Rooij' <guido@gvr.org>, Archie Cobbs <archie@dellroad.org> Cc: David Kelly <dkelly@HiWAAY.net>, Scott Ullrich <sullrich@CRE8.COM>, "'greg.panula@dolaninformation.com'" <greg.panula@dolaninformation.com>, FreeBSD-stable@FreeBSD.ORG Subject: RE: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION A ND QUESTIONS Message-ID: <2F6DCE1EFAB3BC418B5C324F13934C9601D23C5C@exchange.corp.cre8.com>
next in thread | raw e-mail | index | archive | help
Guido, I have the exact scenario that you are recommending. I created the gif devices just as you suggested and the whole nine yards. It seems to me that the "hack" needs to go back into place until this problem is solved, no? -Scott -----Original Message----- From: Guido van Rooij [mailto:guido@gvr.org] Sent: Tuesday, November 19, 2002 2:42 PM To: Archie Cobbs Cc: David Kelly; Scott Ullrich; 'greg.panula@dolaninformation.com'; FreeBSD-stable@FreeBSD.ORG Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS On Tue, Nov 19, 2002 at 10:56:25AM -0800, Archie Cobbs wrote: > Guido van Rooij wrote: > > > The problem is that while ESP packets arrive to be processed by > > > IPsec just fine thru my ipfw rules, when the packets are de-encrypted > > > and re-inserted into the kernel they appear to ipfw to be coming from > > > my external interface (the one they arrived on via ESP). tcpdump can't > > > find them (decrypted) on the external interface. > > I think the bug is that in esp4_input() the "detunneled" packet is > placed back onto the IP input queue 'ipintrq' without the > 'm->m_pkthdr.rcvif' being updated to point to the gif interface. There is no gif interface in that case. Argh. In the ESP tunnel case, the packet is decrypted and the payload is placed on the ipintrq indeed. The problem here is that there is a de-tunneled packet that has no new interface associated. What a mess :-( I now understand why having a dedicated interface for these packets is coming from. A quick work around for people is to use a gif device and have a transport policy for the tunnel endpoints. Then filter ESP on the physical interface and filter on content on the gif interface. (or allow anything in to remain compatible with the ol (IMHO broken) behaviour). So suppose you had the following policy: esp/tunnel/192.168.100.2-192.168.100.1/require then: 1) change that to esp/transport/192.168.100.2-192.168.100.1/require 2) add a gif device on 192.168.100.2 with: gifconfig gif0 create gifconfig 192.168.100.2 192.168.100.1 ifconfig gif0 10.0.0.1 10.0.0.2 3) add a gif device on 192.168.100.1 with: gifconfig gif0 create gifconfig 192.168.100.1 192.168.100.2 ifconfig gif0 10.0.0.2 10.0.0.1 A real solution would be to introduce a new device, esp0 or something to which all ESP decapsulations are send _from tunnel SA's only_. This esp0 would do nothing more then set the rcvif field in the mbuf and put the packet on ipintrq. The old behaviour with ipsec history is wrong and was a hack to get around the problems you people are seeing right now. Comments welcome -Guido To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2F6DCE1EFAB3BC418B5C324F13934C9601D23C5C>