Re: IPsec/gif VPN tunnel packets on wrong NIC in ipfw? SOLUTION AND QUESTIONS
Archie Cobbs: Guido van Rooij wrote: An esp0 or ipsec0 device would provide the handle ipfw needs. That is excatly what I wanted to say earlier. But beware: this is only true in tunnel mode. In transport mode, the KAME stack calls the subprotocol handler directly and, unless you set up your ipsec such that the decrypted packets actually are tunneled packets using a gif interface, you will never be able to catch the packets with a packet filter! This should be easy to fix though. Just have esp_input() requeue the packets on ipintrq instead of calling (*inetsw[ip_protox[nxt]].pr_input) directly. Of course, resetting m-m_pkthdr.rcvif to an appropriate value (esp0 or whatever) would have to be done first. While I (very roughly) understand how it could be implemented, I don't understand how this would work with ESP transport mode. With transport mode, the IP addresses remain unchanged, so essentially we are using publicly routable addresses, and commonly these are on the physical interfaces. How do we make the packets go to esp0 first instead of directly to the physical interface (where the routing table points them to)? Seems to me that we need some trickery routing using shadow routes to make this work, similar to using gif interfaces with ESP tunnel mode. This would add another point of confusion and violate POLA. Seems to me that an esp0 interface is really only useful for ESP tunnel mode. In that case it should be a point-to-point interface similar to gif. Perhaps worth mentioning: ESP transport mode over a gif tunnel is *not* the same as ESP tunnel mode. Having a FreeBSD box with transport mode/gif work against a non-FreeBSD machine in ESP tunnel mode will not work. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
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 [EMAIL PROTECTED] with unsubscribe freebsd-stable in the body of the message
