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
[email protected]
leftsendcert=never
leftsourceip=%config
right=saturn.foobar.com
[email protected]
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
inet 192.168.50.159/24 brd 192.168.50.255 scope global eth0
inet 10.10.2.147/32 scope global eth0
inet6 fe80::216:76ff:feca:bb27/64 scope link
valid_lft forever preferred_lft forever
r...@jupiter:/opt/strongswan/sbin# ip route show
192.168.50.0/24 dev eth0 proto kernel scope link src 192.168.50.159
172.16.250.0/24 dev eth1 proto kernel scope link src 172.16.250.1
169.254.0.0/16 dev eth1 scope link metric 1000
default via 192.168.50.1 dev eth0 metric 100
r...@jupiter:/opt/strongswan/sbin# ip route show table 220
172.17.0.0/16 via 192.168.50.1 dev eth0 proto static src 10.10.2.147
r...@jupiter:/opt/strongswan/sbin# iptables -L -t filter -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 172.17.0.0/16 10.10.2.147 policy match
dir in pol ipsec reqid 1 proto 50
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 172.17.0.0/16 10.10.2.147 policy match
dir in pol ipsec reqid 1 proto 50
ACCEPT all -- 10.10.2.147 172.17.0.0/16 policy match
dir out pol ipsec reqid 1 proto 50
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all -- 10.10.2.147 172.17.0.0/16 policy match
dir out pol ipsec reqid 1 proto 50
r...@jupiter:/opt/strongswan/sbin# iptables -L -t nat -n
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all -- 172.16.250.0/24 0.0.0.0/0
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Couple of limitations, of course.
We can't fiddle with the setup of saturn, sadly. It's a production system
in constant use and can not be changed.
Also, we can't give saturn knowledge of ip addresses being used by
jupiter's satellites. This is because we want to set up further machines
on the lan (e.g. mars, earth, neptune, etc.), each with their own set of
satellites, all using the same address range as jupiter's satellites (e.g.
172.16.250.x) and all connecting ONLY to saturn's satellites. So,
satellites for mars would not need to connect to satellites of jupiter.
Phew! Hope that is not too complicated a situation and that someone can
see the obvious (and, probably, silly) mistake or assumption I've made.
Graham.
_______________________________________________
Users mailing list
[email protected]
https://lists.strongswan.org/mailman/listinfo/users
