Date: Thu, 25 Oct 2001 14:22:40 +0200 (CEST) From: vita@fio.cz To: stable@freebsd.org Subject: RE: IPFW/IPSEC/NAT interaction issues with 4.4, Bug ??? Message-ID: <XFMail.20011025142240.vita@fio.cz> In-Reply-To: <XFMail.20011025140636.vita@fio.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
Maybe ipsec_clearhist() should be called somewhere?
It seems it's never called.
vita
On 25-Oct-2001 vita@fio.cz wrote:
> I have similar configuration and same problem.
> I have compiled several log messages to my kernel
> and it looks as follows:
>
>
> After EPS decapsulation packet is re-injected to input queue
> and then processed by ip_input.
> On line 402 ( ip_input.c, 4.4-RELEASE )
> is
>
> if (ipsec_gethist(m, NULL ))
> goto pass;
>
> Condition is true and firewall skipped.
>
> Is it feature or bug?
>
>
> Vita
>
>
>
>
>
> On 23-Oct-2001 Barry Irwin wrote:
>>
>> 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
>
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the 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?XFMail.20011025142240.vita>