Skip site navigation (1)Skip section navigation (2)
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>