Date: Tue, 19 Nov 2002 07:54:29 -0600 From: David Kelly <dkelly@HiWAAY.net> To: Guido van Rooij <guido@gvr.org>, Scott Ullrich <sullrich@CRE8.COM> Cc: "'Archie Cobbs'" <archie@dellroad.org>, "'greg.panula@dolaninformation.com'" <greg.panula@dolaninformation.com>, FreeBSD-stable@FreeBSD.ORG Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Message-ID: <200211190754.29355.dkelly@HiWAAY.net> In-Reply-To: <20021119110336.GA12956@gvr.gvr.org> References: <2F6DCE1EFAB3BC418B5C324F13934C9601D23C35@exchange.corp.cre8.com> <20021119110336.GA12956@gvr.gvr.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tuesday 19 November 2002 05:03 am, Guido van Rooij wrote: > On Sun, Nov 17, 2002 at 05:44:38PM -0500, Scott Ullrich wrote: > > I have reverted back to revision 1.130.2.39 of ip_input.c and that > > solved my issues! > > > > Guido, I am running IPFW2. If there is anything you need from me > > to help fix this issue, please let me know. > > I am not convinced that anything needs to be fixed. > From reading the thread in -stable, I can not see what you are trying > to do. > > If you are using gif tunnels for ipsec, where the packets are sent > into a gif tunnel and then, using the encapsulated packets, are > encrypted, then indeed there is a change. > The change is that packets going into, and coming out of, the gif > tunnel are from now on filtered as well. And this is exactly what is > to be expected. So you'll need a rule on the physical interfase > allwoing ESP/AH packets and ISAKMP traffic, and on the gif interface > you'll need rules for the unencrypted content of the packets. > > If you have another setup, please explain how it is setup and I can > try to understand if anything is wrong. I think I confused matters by my configuration of a VPN which was one of those things I took shots at until it worked then documented what I had done and continued to use that configuration until recently when it broke. While I was configuring gif0, at least partially, it wasn't in use. Was a matter of I didn't know what I was doing or what was really needed and didn't go back removing things. 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. Am not using AH. Maybe I should? Still using plain ipfw. The issue I have with this is that I have/had antispoofing rules forbiding 192.168.0.0/16 via external NIC but because my remote net which is being tunneled is in that range I have had to open a rule on the external interface to allow it. This rule allows external internet and my VPN traffic. One end of the tunnel is in 10.0.0.0/24 and the other end is in 192.168.100.0/24. I don't mind these packets being run thru ipfw twice. Its just that they are unique in their own way for how they got here but are not being identified with a unique interface. If they were appearing on gif0 there wouldn't be an issue. Suspect this is related to ipfw changes recently. Should we add the ipfw list to the discussion? Another way of saying it, "had to add rule 550 for my tunnel to work:" 00100 6382 2963406 allow ip from any to any via lo0 00200 0 0 deny ip from any to 127.0.0.0/8 00300 0 0 deny ip from 127.0.0.0/8 to any 00400 0 0 deny ip from 10.0.0.0/24 to any in recv fxp1 00500 0 0 deny ip from 24.214.110.0/24 to any in recv fxp0 00550 29238 3166400 allow ip from 192.168.100.0/24 to 10.0.0.0/24 in recv fxp1 00600 0 0 deny ip from any to 10.0.0.0/8 via fxp1 00700 0 0 deny ip from any to 172.16.0.0/12 via fxp1 00800 0 0 deny log ip from any to 192.168.0.0/16 via fxp1 00900 0 0 deny ip from any to 0.0.0.0/8 via fxp1 01000 0 0 deny ip from any to 169.254.0.0/16 via fxp1 01100 0 0 deny ip from any to 192.0.2.0/24 via fxp1 01200 0 0 deny ip from any to 224.0.0.0/4 via fxp1 01300 13738 4506273 deny ip from any to 240.0.0.0/4 via fxp1 01400 787470 364186135 divert 8668 ip from any to any via fxp1 [...] -- David Kelly N4HHE, dkelly@hiwaay.net ===================================================================== The human mind ordinarily operates at only ten percent of its capacity -- the rest is overhead for the operating system. 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?200211190754.29355.dkelly>