Date: Tue, 23 Oct 2001 10:45:22 +0200 From: Barry Irwin <bvi@itouchlabs.com> To: snap-users@kame.net, ipfw@freebsd.org Subject: IPFW/IPSEC/NAT interaction issues with 4.4 Message-ID: <20011023104522.E87507@itouchlabs.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011023104522.E87507>