Date: Fri, 15 Nov 2002 21:23:53 +0100 (CET) From: Helge Oldach <freebsd-stable-15nov02@oldach.net> To: dkelly@hiwaay.net (David Kelly) Cc: freebsd-stable@freebsd.org Subject: Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? Message-ID: <200211152023.gAFKNrCZ022114@sep.oldach.net> In-Reply-To: <20021115145342.GA4032@grumpy.dyndns.org> from David Kelly at "Nov 15, 2002 8:53:42 am"
next in thread | previous in thread | raw e-mail | index | archive | help
David Kelly: > Have a suspicion I'm not really using gif altho I've configured the > interfaces. Earlier yesterday found I had not updated an IP address in > the gif0 device which changed a month or to prior. Yet things were still > working. There is no need to use gif(4) for gateway-to-gateway communications, as on a gateway you usually have a designated inside and outside (= public) NIC, with the IP address of the outside NIC being used as the IPSec peer. The only reason to use gif is if you don't run a VPN gateway but a host and use ESP in tunnel mode: In this case the outside NIC is the IPSec peer, but you need an inside IP address as well. There is some lack of flexibility with common Unix networking stacks compared to "real" routers, so the gif interface is being employed to get the routing to the remote side straight. This adds confusion: while gif(4) is a tunnel interface it is in fact not used. What actually happens is that your packets attempt to "enter" the gif interface, are caught by IPSec and placed into the ESP tunnel which essentially rewrites their IP address, and makes them being sent according to the routing table to the outside interface. Hence your packet counters on gif are always zero. If you don't like gif because it violates the rule of least astonishment, another option would be to assign a secondary (oops Cisco lingo - in BSD terms: alias :-)) address to the outside interface and set up a route to the private remote side via your default gateway. You need to add a static ARP entry using the MAC address of your default gateway with the private remote side IP address to make the routing working. Another natural choice would be a loopback interface (say lo1), but for some reason I don't understand this doesn't work. Likely some packet chomping optimization of loopbacks. Regards, Helge 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?200211152023.gAFKNrCZ022114>