Date: Thu, 25 Oct 2001 19:13:02 -0700 (PDT) From: Mike Harding <mvh@ix.netcom.com> To: vita@fio.cz Cc: stable@freebsd.org Subject: Re: IPFW/IPSEC/NAT interaction issues with 4.4, Bug ??? Message-ID: <20011026021302.5EE59134D2@netcom1.netcom.com> In-Reply-To: <XFMail.20011025140636.vita@fio.cz> References: <XFMail.20011025140636.vita@fio.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a feature - if you don't do this, you can't tell decapsulated
traffic from raw traffic. That was the old config. If you have a
router, you can filter on the inside interface. I suggested inserting
the traffic on a fake interface so you could do more interesting
things like NAT, better filtering, etc, but some KAME folk seemed to
get very upset about this, although I couldn't follow the reasoning...
- Mike H.
X-Envelope-From: vita@fio.cz
X-Priority: 3 (Normal)
Date: Thu, 25 Oct 2001 14:06:36 +0200 (CEST)
Organization: FIO holding
From: vita@fio.cz
Sender: owner-freebsd-stable@FreeBSD.ORG
X-Loop: FreeBSD.ORG
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?20011026021302.5EE59134D2>