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 >> [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 _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
