Date: Fri, 31 Oct 2003 09:45:25 -0600 From: Mark Johnston <mjohnston@skyweb.ca> To: "Crist J. Clark" <cjc@freebsd.org> Cc: security@freebsd.org Subject: (long) Re: Using racoon-negotiated IPSec with ipfw and natd Message-ID: <20031031154525.GA985@omoikane.mb.skyweb.ca> In-Reply-To: <20031030224342.GA32640@blossom.cjclark.org> References: <20031030210509.GA667@omoikane.mb.skyweb.ca> <20031030224342.GA32640@blossom.cjclark.org>
next in thread | previous in thread | raw e-mail | index | archive | help
"Crist J. Clark" <cristjc@comcast.net> wrote:
> On Thu, Oct 30, 2003 at 03:05:09PM -0600, Mark Johnston wrote:
> > - gateway receives an ESP packet from mobile (encapsulating a ping).
> > - gateway decrypts and transmits an ICMP packet to internal with mobile's
> > source address.
> > - internal generates the ICMP response to mobile.
> > - gateway receives the response, runs it through natd, and sends it out in the
> > clear to mobile with gateway's source address.
>
> This shouldn't happen. IPsec processing of the outgoing packet happens
> _before_ it gets passed to ipfw(8) (which hands it to natd(8)) on the
> external interface.
That's odd. To simplify the situation a bit, I'm testing with a static
SP/SA set. The SPs in place are:
172.21.0.0/16[any] 192.168.15.0/24[any] any
in ipsec
esp/tunnel/remoteext-localext/require
spid=122 seq=1 pid=12464
refcnt=1
192.168.15.0/24[any] 172.21.0.0/16[any] any
out ipsec
esp/tunnel/localext-remoteext/require
spid=121 seq=0 pid=12464
refcnt=1
(The external IPs are missing but the rest is unchanged.)
I can break and fix the connection by adding and removing firewall rules
allowing the traffic before the natd divert.
> > What I want to
> > accomplish, in pseudo-ipfw, is this:
> >
> > pass esp from any to me
> > pass ip from known-sp-sources to 192.168.0.0/24
> > pass ip from 192.168.0.0/24 to known-sp-destinations
> > divert natd from 192.168.0.0/24 to any
>
> This may be your problem. That rule should be something like,
>
> divert natd from 192.168.0.0/24 to any via ${external_if}
>
> Is that what you actually have? Are you doing NAT on the internal
> interface? That would confuse things.
I'm not sure what you mean by "doing NAT". The natd interface (-n) is the
external one, but I'm diverting to natd using a recv rule on the internal
interface. The natd setup is a bit hairy, because the box has a DMZ
interface (dc0) along with external (fxp0) and internal (txp0) NICs, which
is bridged (dc0-fxp0) instead of routed to match a legacy config. Here's
my current ipfw setup:
00100 allow esp from any to me
00200 allow ah from any to me
00205 allow udp from any to me dst-port 500
00210 allow ip from 192.168.15.0/24 to 172.21.0.0/16
00220 allow ip from 172.21.0.0/16 to 192.168.15.0/24
[ more bidirectional allow rules ]
00300 deny ip from any to 192.168.15.0/24 in recv fxp0
00400 deny ip from any to 192.168.15.0/24 in recv dc0
00500 divert 8669 ip from 192.168.15.0/24 to not me recv txp0
00600 divert 8668 ip from any to me in recv fxp0
00700 divert 8668 ip from any to me in recv dc0
00800 allow ip from 192.168.15.0/24 to any recv txp0
00900 allow ip from any to 192.168.15.0/24
01000 check-state
[ some allows and denies for fxp0<->dc0 ]
01800 allow ip from 192.168.15.0/24 to me
01900 allow ip from me to any keep-state
65535 deny ip from any to any
Because of the DMZ, I had to tweak the natd setup to use -i 8668 -o 8669
- if I diverted everything to 8668 and didn't use -i and -o, it was
interpreting dc0 as "inside", and I couldn't communicate with the DMZ from
the LAN.
With these rules in place, everything works fine, and I can ping across
the IPsec link. If I delete 210 and 220, I start to see the pings on fxp0
destined to the 172.21.x.x address from my external IP.
Also, sysctl.conf has some variables related to the config:
net.inet.ip.fw.one_pass=0
net.link.ether.bridge_cfg=fxp0,dc0
net.link.ether.bridge=1
net.link.ether.bridge_ipfw=1
net.key.prefered_oldsa=0
Thanks for your help with this. I guess that the trouble is that I don't
totally grok the ipfw/natd/ipsec tie-ins.
Mark
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031031154525.GA985>