Date: Thu, 02 Jan 2003 16:06:11 +0200 From: Pekka Nikander <pekka.nikander@nomadiclab.com> To: freebsd-net@FreeBSD.ORG Subject: IPsec / ipfw interaction in 4.7-STABLE: a proposed change Message-ID: <3E144753.7020905@nomadiclab.com>
next in thread | raw e-mail | index | archive | help
A fairly recent change in 4.7-STABLE modified the way IPsec ESP tunneled packets are handled by the ipfw code. There was a brief thread on this at the freebsd-stable mailing list in the end of November, see for example http://docs.freebsd.org/cgi/getmsg.cgi?fetch=270433+0+archive/2002/freebsd-stable/20021201.freebsd-stable Earlier on packets received from an ESP tunnel were passed directly up; now they are processed again by ipfw. An example of worked fine before: # ipfw show 00100 allow esp from XX.XX.XX.XX to MY.IP.ADD.RRS in recv xl0 00110 allow esp from MY.IP.ADD.RRS to XX.XX.XX.XX out xmit xl0 00200 deny ip from 192.168.0.0/24 to 192.168.0.0/24 via xl0 # setkey -DP 192.168.0.192/29 192.168.0.0/24 any in ipsec esp/tunnel/XX.XX.XX.XX-MY.IP.ADD.RRS/require 192.168.0.0/24 192.168.0.192/29 any out ipsec esp/tunnel/MY.IP.ADD.RRS-XX.XX.XX.XX/require Under the old behaviour the ipfw rule 200 explicitly forbid unprotected traffic using the tunneled addresses from getting out or in via the external interface, xl0. This rule can't be used any more, since now it blocks incoming traffic, and it must be replaced by something that allows incoming traffic from the tunnel. Thus, the change has the undesired side effect that it is now impossible to use ipfw to protect the tunnel end-point from traffic that looks like coming from the tunnel but does not come after all. From the security point of view this does not matter so much, since the IPsec code is taking care of the protection and dropping those packets. However, in the case where the IPsec policies get screwed up (e.g. due to racoon failure...) security may be somewhat weaker than before. At the stable -list someone suggested for a fix where the packets coming from the ESP tunnel would be changed so that they look like coming grom another interface. A proper fix would probably require a real "esp" pseudo-interface, but that should be carefully considered and tested to see that routing etc. would work fine. Now, as a small step to that direction I made the following small hack to netinet6/esp_input.c It changes the ESP tunneled packets to look like they were coming from the loopback interface. And it works like charm. However, this is not a proper fix, and a better one might be to increment NLOOP and use loif[1] instead of loif[0]. Opinions? --Pekka Nikander --- esp_input.c.orig Mon Aug 26 03:09:03 2002 +++ esp_input.c Thu Jan 2 15:40:25 2003 @@ -404,6 +404,9 @@ splx(s); goto bad; } + /* XXX: Interface hack by pnr */ + m->m_pkthdr.rcvif = loif; + /* XXX: End of interface hack by pnr */ IF_ENQUEUE(&ipintrq, m); m = NULL; schednetisr(NETISR_IP); /* can be skipped but to make sure */ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E144753.7020905>