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 > [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. ====================================================================== Andreas Steffen [email protected] strongSwan - the Linux VPN Solution! www.strongswan.org Institute for Internet Technologies and Applications University of Applied Sciences Rapperswil CH-8640 Rapperswil (Switzerland) ===========================================================[ITA-HSR]== _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
