Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 23 Oct 2001 16:53:03 +0200
From:      Barry Irwin <bvi@itouchlabs.com>
To:        stable@freebsd.org
Subject:   IPFW/IPSEC/NAT interaction issues with 4.4, Bug ???
Message-ID:  <20011023165303.A24235@itouchlabs.com>

next in thread | raw e-mail | index | archive | help

I have had no luck with this on the ipfw or KAME lists :< maybe someone here
can help , I have a horrible feeling that I have stumbled across a rather
nasty bug.


Hi All

I'm hoping someone here can shed some light on a problem I came across this
morning. I have two VPN gateways connected to cisco VPN concentrators. 
These are running Freebsd 4.2-RELEASE and 4.4-RELEASE.  The 4.2 based
gateway has been functioning without hastles for a while now.  however when
I configured the 4.4 based system this morning, I ran into the problem that
the IP packets seem to ne be being re-injected into the firewall ruleset
after the ESP decapsulation.  The firewall rulesets are identicle between
the systems.  This re-injection is neccessary for me to be able to then
place the packet into a divert socket feeding natd, and from there onto the
client machines behind the VPN gateway.

Network diagram is as follows:

[SERVER] - [FW] - [VPNC] --{INTERNET}-- [FBSD VPN GW/FW] -- [CLIENT]

I can connect fine from the firewall itself to the SERVER.  

bash-2.05# telnet S.S.S.22 2300
Trying S.S.S.22...
Connected to S.S.S.22.
Escape character is '^]'.
^]
telnet> q
Connection closed.

The firewall rules in place at this time are:
00040 allow udp from any 500 to any 500
00045 allow esp from any to any
00046 deny ip from S.S.S.22/24 to any
65535 allow ip from any to any

My understanding is that rule 46 would deny the traffic, however an ipfw
show 46 indicates that the rules is NOT matching ANY packets!
bash-2.05# ipfw show 45 46
00045       9       896 allow esp from any to any
00046       0         0 deny ip from 203.20.35.0/24 to any

Connections from the client are correctly natted, and go out, responses
however also seem to be accepted by the FBSD firewall immediately after
decryption.

[bvi@client1 bvi]$ netstat -tn | grep 203
tcp        0      1 192.168.10.2:1615       203.20.35.22:2300       SYN_SENT

and on the firewall
Oct 23 18:13:38 off-fw1 /kernel: Connection attempt to TCP B.B.B.8:1615 from S.S.S.22:2300
Oct 23 18:13:56 off-fw1 last message repeated 2 times
Oct 23 18:14:20 off-fw1 /kernel: Connection attempt to TCP B.B.B.8:1615 from S.S.S.22:2300

this proves that the packets are getting accepted by default witout the 
reinjection after decoding. B.B.B.8 being the IP address of the firewall,
the endpoint of the VPN IPSEC/ESP Tunnel and the Address to which traffic
from the client network is natted.  The same setup works fine on the 4.2
system.   

My understanding of the packet flow process is:
INet -> packet received with ESP -> passed through IP firewall ruleset 
     -> packet matching IPSEC SP -> YES - Decrypt and re-inject
                                 ->  NO IS it ipsec -> yes discard
                                                  -> no re-inject
   -> reinjected packets passed through ipfirewall again
   -> ipfw passes packets off to NAT and things WORK :>>

With 4.4
 The process should work as above, however the packet appears to being 
accepted by the host as soon as it has been decrypted. 

Have checked the sysctls for ipsec, and the are the same, except for the
adddition of the following one on the 4.4 box (which is undocumented??)
net.inet.ipsec.esp_randpad: -1

Full sysctl output from the 4.4 box is:

bash-2.05# sysctl -a | grep ipsec
net.inet.ipsec.def_policy: 1
net.inet.ipsec.esp_trans_deflev: 1
net.inet.ipsec.esp_net_deflev: 1
net.inet.ipsec.ah_trans_deflev: 1
net.inet.ipsec.ah_net_deflev: 1
net.inet.ipsec.ah_cleartos: 1
net.inet.ipsec.ah_offsetmask: 0
net.inet.ipsec.dfbit: 0
net.inet.ipsec.ecn: 0
net.inet.ipsec.debug: 1
net.inet.ipsec.esp_randpad: -1

NAT is operaring fine for all the connections NOT going through the IPSEC
encapsulation.

My thinking is that this is a bug in the IPSEC ESP handling in the version
of the KAME stack integrated into 4.4?  Has anyone got similar problems,
suggestions for a fix ?

Barry

--
Barry Irwin
Systems Administrator (Networks and Security)
Itouch Labs
bvi @ itouchlabs.com


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-ipfw" in the body of the message



----- End forwarded message -----


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?20011023165303.A24235>