[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
[strongSwan] setkey equivalent tool available?
Is there a tool in strongSwan which performs the functions as in 'setkey' in racoon? Thanks, -Yong Cho ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] setkey equivalent tool available?
strongSwan is an automatic keying daemon and therefore does not need any manual IPsec SA configuration tool. For monitoring purposes either the command ip -s xfrm state|policy or ipsec statusall can be used. Andreas Yong Choo wrote: Is there a tool in strongSwan which performs the functions as in 'setkey' in racoon? Thanks, -Yong Cho == 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
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
