Hi Graham,
I believe Andreas is correct. I just tried this here with my own setup.
You can't depend on the MASQUERADE target if you want to source nat to
the gateway's virtual IP address. This is what the man page says about
MASQUERADE:
Masquerading is equivalent to specifying a mapping to the IP address of
the interface the packet is going out
I infer that the kernel does not check the routing table when it selects
an IP address as the source address.
Try something like
iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -d 172.17.0.0/16 -i
eth1 -o eth0 -j SNAT --to-source 10.10.2.147
If the address 10.10.2.147 is not static then you might need to come up
with some fancy scripts that change the iptable rules everytime the
IPsec tunnel comes up.
-Daniel
Andreas Steffen wrote:
Hello Graham,
the problem might be that although jupiter's satellites are NAT-ed
to jupiter's eth0 address 192.168.50.159, jupiter itself uses the
virtual IP address 10.10.2.147 within the IPsec tunnel. I know
from personal experience that NAT-ing clients behind a gateway
to the gateway's outer IP address will successfully route traffic
through the tunnel (at least with Linux kernels = 2.1.16 which
fixed a longstanding bug) but since the POSTROUTING -t nat chain
is the last hook in the path it will not heed the source routing
rule defined by table 220. Can you do without a virtual IP on jupiter?
Regards
Andreas
Graham Hudspith wrote:
Hi,
I have a situation which I hope someone can please help me with.
I have a machine (called jupiter) on our lan. Using it's eth0 NIC (we're
talking linux, of course), jupiter can ping and connect to other machines
on the lan. One machine it can reach (called saturn) acts as a gateway to
a further network of machines (e.g. mimas, rhea, titan, etc.). These
satellite machines can not be contacted directly by jupiter, they are
hiding behind saturn. To get at them, jupiter has to set up a strongSwan
tunnel.
Once the tunnel is set up, jupiter can ping and connect to all of saturn's
satellites.
So far, so good.
Now, we also have a network of machines hiding from the lan behind
jupiter. These satellites of jupiter (e.g. io, europa, ganymede, etc.)
are connected to jupiter's eth1 NIC. I've turned on ipv4 forwarding on
jupiter and added an iptables nat rule to jupiter to allow these
satellites access to the lan.
However, the problem is that I have not found a way to allow jupiter's
satellites access, through the tunnel, to saturn's satellites ?
Is there something obvious I have missed ?
Now for the details ...
Our default gateway is 192.168.50.1
saturn has ip address 172.16.2.2
saturn's satellites have ip addresses in the range 172.17.x.x, e.g. titan
(one of saturn's satellites) has ip address 172.17.100.151
jupiter has ip address 192.168.50.159 (acquired by dhcp from the lan for
eth0) and 172.16.250.1 (statically assigned by jupiter for eth1).
jupiter's satellites have ip addresses in the range 172.16.250.100-200
served by dnsmasq running on jupiter for eth1.
At start-up, jupiter allows access to the lan for it's satellites via:
iptables -t nat -A POSTROUTING -s 172.16.250.0/24 -o eth0 -j MASQUERADE
echo 1 /proc/sys/net/ipv4/ip_forward
Jupiter then sets up a strongswan (v4.3.2) tunnel using the following
ipsec.conf:
config setup
charondebug=dmn 4, mgr 4, ike 4, chd 4, job 4, cfg 4, knl 4, net 4, enc
4, lib 4
plutostart=no
conn %default
ikelifetime=24h
keylife=8h
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
conn access-saturn-satellites
left=%defaultroute
leftid=036439001...@gan.mnc390.mcc364.3gppnetwork.org
leftsendcert=never
leftsourceip=%config
right=saturn.foobar.com
right...@saturn.foobar.com
rightsubnet=172.17.0.0/16
authby=eap
forceencaps=yes
ike=aes128-sha-modp1024!
mobike=no
auto=start
With the tunnel set up, ganymede (one of jupiter's satellites) can ping
machines on the lan, but NOT ping saturn's satellites. The icmp request
packets are sent out by jupiter onto the lan (and are therefore ignored)
instead of being sent out over the tunnel to saturn.
r...@jupiter:/opt/strongswan/sbin# ip addr show
1: lo: LOOPBACK,UP,LOWER_UP mtu 16436 qdisc noqueue state UNKNOWN
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth1: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 00:17:3f:9b:8c:ad brd ff:ff:ff:ff:ff:ff
inet 172.16.250.1/24 brd 172.16.250.255 scope global eth1
inet6 fe80::217:3fff:fe9b:8cad/64 scope link
valid_lft forever preferred_lft forever
3: eth0: BROADCAST,MULTICAST,UP,LOWER_UP mtu 1500 qdisc pfifo_fast state
UP qlen 1000
link/ether 00:16:76:ca:bb:27 brd ff:ff:ff:ff:ff:ff
