Date: 20 Nov 2002 00:15:31 -0600 From: Craig Boston <craig@meoqu.gank.org> To: freebsd-stable@freebsd.org Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Message-ID: <1037772931.287.17.camel@aldaris2.auir.gank.org> 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
Kind of a "me too", but only loosely related, I've seen some strange behavior with gif tunnels and firewalls... Basically I have the following setup: Net A <-> Router A <-> Internet <-> Firewall C <-> Router B <-> Net B Router B initiates a tunnel out to Router A. Router A has its own firewall compiled in; Router B doesn't since it's behind a hardware firewall. Now, when I initiate a connection from Net A to Net B, all is well with a rule (on Router A) that allows traffic out on gif0. This works and shows hits on it. The problem only surfaces when I want to connect from a host in Net B to one in Net A. If I have a rule like so: pass in quick on gif0 proto tcp from 172.x.y.z to 192.x.y.z port = 22 keep state It doesn't actually work; no hits on it and no traffic is allowed. However, if I write a rule like this: pass out quick on ex0 proto tcp from 172.x.y.z to 192.x.y.z port = 22 keep state where ex0 is the internal interface for Net A, all is well. Note that this works without ANY rule allowing traffic "in" on gif0. tcpdump, however, does see the traffic comming "in" on gif0. Even more curious are entries like this in the state table: 172.x.y.z -> 192.x.y.z ttl 12479 pass 0x5006 pr 6 state 6/3 pkts 15 bytes 2443 1859 -> 22 63f53b44:3efc217b 2<<254:57344<<0 pass out quick keep state IPv4 pkt_flags & 2(b2) = b, pkt_options & ffffffff = 0 pkt_security & ffff = 0, pkt_auth & ffff = 0 interfaces: in -,ex0 out ex0,gif0 Huh? What's with the "-,ex0" for interfaces in? That's totally wrong; the outer UDP packet came in via ex1, went through tun0 (I'm using PPPoUDP since my hardware firewall doesn't grok other IP protocols), got decrypted, and finally ended up on gif0. Now, I AM running 4.6-STABLE as this is a 486 with a flash ram chip and I haven't had a chance / reason to upgrade it. It also may be an ipf(4)-specific problem (yes, I do know I'm threadjacking an ipfw discussion, but it seemed somehow related :) I may try ipfw to see if it behaves any differently, but I'm currently dependant on some ipnat-specific features so it's not really a long-term solution. Anybody run into this before? Is this at all related to the current discussion? Craig 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?1037772931.287.17.camel>