[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: pf does not pass esp?
On Thu, 21 Mar 2002 11:42:26 -0800
Jason Ish <jason@codemonkey.net> hit the keyboard and punched:
> > I have a custom kernel, but I do have enc0. It just wasn't up.
> > Anyways, added a nat rule like that, and what do you know, it
> > works. Almost. Now the connection is 50% encrypted :-/
> >
> > tcpdumping on enc0 gives:
> > 20:23:13.246779 (authentic,confidential): SPI 0x1f644dae:
> > 130.236.218.63.1747 > 213.88.128.171.1494: . ack 1681 win 33304
> > <nop,nop,timestamp 6070771 6142364> (DF) (encap)
> >
> > while tcpdumping on xl1 gives:
> > 20:23:13.809282 0:10:4b:cf:1f:e0 0:c0:7b:a3:71:b6 0800 66:
> > 213.88.128.171.1494 > 130.236.218.63.1747: . ack 16099 win 16122
> > <nop,nop,timestamp 6142370 6070827> (DF)
> >
> > Seems as the return traffic wont go through the tunnel :-/
>
> Add an outbound flow for your private network..
One interesting observation...
pinging 213.88.128.173 (the OpenBSD gateway) from 130.236.218.63
(my home freebsd box) will return traffic in tunnel (ie both
icmp request and reply visible with tcpdump enc0)
But when pinging 213.88.128.whatever (which is binated 10.0.0.whatever)
the return traffic goes outside the tunnel. How come it works when
pinging GW itself and not when pinging binated ip?
> ipsecadm flow -proto esp -src <your ip> -dst <remote endpoint ip> \
> -addr <private net>/<mask> <remote net>/<mask> -out \
> {-dontacq/-require/whatever}
>
> The tunnel will then pick up the traffic, then NAT it, then encrypt it.
Thanks, again! That did the trick, again! *happy*
So, if the tunnel goes down (ie isakmpd dies), will I have to reenter
this command? Should I put it into any kind of startup script?
--
Rickard
.--. .--.
.----------------------------------------. | | | | .-.
| Rickard Borgmäster | | | | |/ /
| doktorn@sub.nu | .-^ | .--. | <
| http://doktorn.sub.nu/ | ( o | ( () ) | |\ \
`----------------------------------------' `-----' `--' `--' `--'