Re: [strongSwan] Sending eth1 traffic down eth0 tunnel
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
Re: [strongSwan] Sending eth1 traffic down eth0 tunnel
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? Andreas, Thanks for that swift reply. I tried setting up the tunnel WITHOUT specifying the sourceip option in the ipsec.conf. The tunnel does come up, and the left side of the tunnel is assigned jupiter's IP address. However, if I send a ping from jupiter to one of saturn's satellites, the pings go down the tunnel to the remote security-gateway (saturn) and onwards to the far subnet (saturn's satellites), BUT the reply seems to come from saturn back cleartext on the LAN rather than through the tunnel. The ping replies are not routed back to the originator on jupiter. If I send a ping from one of jupiter's satellites to one of saturn's satellites, this does now go down the tunnel. However, the results are the same, in that the ping reply is sent cleartext from saturn on the LAN rather than down the tunnel. Any ideas what I can do to fix this (only allowed to alter jupiter, sadly) ? Regards, Graham. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Sending eth1 traffic down eth0 tunnel
Hi Graham, what if you NAT the clients behind Jupiter to Jupiter's virtual IP? As far as I remember this should work. Regards Andreas Graham Hudspith wrote: 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? Andreas, Thanks for that swift reply. I tried setting up the tunnel WITHOUT specifying the sourceip option in the ipsec.conf. The tunnel does come up, and the left side of the tunnel is assigned jupiter's IP address. However, if I send a ping from jupiter to one of saturn's satellites, the pings go down the tunnel to the remote security-gateway (saturn) and onwards to the far subnet (saturn's satellites), BUT the reply seems to come from saturn back cleartext on the LAN rather than through the tunnel. The ping replies are not routed back to the originator on jupiter. If I send a ping from one of jupiter's satellites to one of saturn's satellites, this does now go down the tunnel. However, the results are the same, in that the ping reply is sent cleartext from saturn on the LAN rather than down the tunnel. Any ideas what I can do to fix this (only allowed to alter jupiter, sadly) ? Regards, Graham. == Andreas Steffen andreas.stef...@strongswan.org 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 Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Sending eth1 traffic down eth0 tunnel
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 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/1610.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/1610.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
Re: [strongSwan] Sending eth1 traffic down eth0 tunnel
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 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
