OK, I finally got racoon to work and have IPsec working great with a
2.6.0-test2-mm1 kernel on my home Internet gateway system. However,
I've hit another issue. In my previous setup with the 2.4.20 kernel and
SuperFreeS/WAN it looked like this
10.0.0.0/8--205.242.242.161<-IPsec->66.3.2.1--{10.250.1.129/32}--192.168.1.0/24
Basically the IPsec tunnel had only a single IP address on the remote
end then any packets from the home internal network (192.168.1.0) were
SNAT to the 10.250.1.129 before being sent via the tunnel. This hid my
home network behind a valid IP at my work network and worked flawlessly
with 2.4 and SuperFreeS/WAN.
I've got the identical setup with kernel 2.6 and racoon. I get the
tunnel up and everything works great from the gateway system, but none
of the systems on my home network can access the systems on the work
network. It seems that packets passing via IPsec are bypassing the NAT
rules, although that's mostly just a guess at this point.
Is there anything written that describes how the kernels IPsec
implementations interacts with iptables? I've searched the linux-kernel
archives and Google but turned up empty (although I found the question
asked one time before). Any help would be greatly appreciated.
Later,
Tom
On Mon, 12 Aug 2003, Tom Sightler wrote:
> OK, I finally got racoon to work and have IPsec working great with a
> 2.6.0-test2-mm1 kernel on my home Internet gateway system. However,
--snip--
> I've got the identical setup with kernel 2.6 and racoon. I get the
> tunnel up and everything works great from the gateway system, but none
> of the systems on my home network can access the systems on the work
> network. It seems that packets passing via IPsec are bypassing the NAT
> rules, although that's mostly just a guess at this point.
Could it be that the *name* of the ipsec device has changed? Messing with
vtun, I did that to myself recently and suffered a similar loss of
connectivity through the tunnel. My solution was an iptables rule saying
that packets going to any interface except the house network get NATted.
James F. Carter Voice 310 825 2897 FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [email protected] http://www.math.ucla.edu/~jimc (q.v. for PGP key)
On Tue, 2003-08-12 at 00:56, Jim Carter wrote:
> Could it be that the *name* of the ipsec device has changed? Messing with
> vtun, I did that to myself recently and suffered a similar loss of
> connectivity through the tunnel. My solution was an iptables rule saying
> that packets going to any interface except the house network get NATted.
Because the new IPsec code is built in there is no "ipsec" device to
speak of. My initial analysis is that FreeS/WAN basically fed a packet
through the system twice, once via the real interface and once via the
tunnel. This allowed for easy separation of rules.
This simply doesn't seem to be the case anymore, packets leaving an
interface are either encrypted or not based on kernel policies set via
setkey. It looks like it's been encrypted before it reaches the
POSTROUTING rule thus precluding it from being NAT'd.
My rule doesn't use an interface anyway, it's this:
iptables -t nat -A POSTROUTING -s ! 10.250.1.129/32 -d 10.0.0.0/8 -j
SNAT --to-source 10.250.1.129
Which basically says if a packet is going to 10.0.0.0/8 and it's source
is not 10.250.1.129 to SNAT it to that address.
Later,
Tom