IPsec / ipfw interaction in 4.7-STABLE: a proposed change

[Pekka Nikander]

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 [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message