[strongSwan] Selector problems with tunnel mode and VRRP addresses and GRE/IPSec
Hello, all. I'm working on a fairly complex setup where we are doing ingress traffic shaping with an IFB interface including traffic transported via GRE/IPSec on gateways using keepalived for VRRP. We would normally use IPSec in transport mode for GRE/IPSec but that seems to prevent the tc filters from seeing the contents of the IPSec packets after decrypted. In tunnel mode, the packet seems to take that second path through the interface and the tc filters work as expected . . . until it breaks. The StrongSWAN gateways use VRRP on their public interfaces. We only run StrongSWAN on the active gateway and the tunnel end points are the VIPs, i.e., the virtual IP addresses assigned by keepalived when the gateway is operating as MASTER. When a gateway fails, it tears down the GRE and IPSec tunnels if it can, and the new MASTER establishes them using the local VIP and terminating on the remote VIP. This worked fine in transport mode but, in tunnel mode, it complains, no local address found in traffic select VIP/32. I've tried playing with left/rightsourceip but this does not seem applicable to what we are doing and breaks. I've tried specifying leftsubnet even though it is the same as left but that does not work. How does one use tunnel mode to a VRRP VIP? Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
Hmmm, I don't think this worked. The pre- and post-VPN routing tables are actually identical: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I then added a new route: # route add -net 172.31.48.0 netmask 255.255.240.0 gw 172.31.48.1 dev eth0 New routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 172.31.48.1 255.255.240.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I still couldn't SSH to 172.31.63.211 while the VPN tunnel is up. Alan On 5/30/15, Zhuyj mounter...@163.com wrote: Check route, 0.0.0.0 is not good, a specific LAN is better 发自我的 iPhone 在 2015年5月30日，7:58，Alan Tu 8li...@gmail.com 写道： Hello, I'm using Strongswan 5.3.0 to successfully connect a Linux machine to a VPN over the Internet. However, after I bring up the VPN tunnel, my client Linux machine cannot talk to other machines on its own LAN, even though it can talk to machines everywhere else on the Internet, as well as to machines on the VPN. Can someone give me a hint as to the solution? My client machine has IP address 172.31.59.36. The eth0 network interface has netmask /20. The pre-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_hostname. 0.0.0.0 UG0 00 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Post-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_ip 0.0.0.0 UG0 00 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Here are some potentially relevant lines from my ipsec.conf file: conn vpn type=tunnel aggressive=yes xauth=client left=%any leftid=keyid:... leftsourceip=%modeconfig right=[public IP of VPN gateway] rightsubnet=0.0.0.0/0 After the Strongswan VPN connection is brought up, and the virtual IP is inserted into eth0, I cannot access other machines in the 172.31.x.x range. The VPN virtual IP addresses are in the 10.0.0.0/8 range, so there is no apparent conflict. I think my root problem is something related to routing, but I don't know how to fix it. Because routing to local servers on the LAN no longer works, non-VPN DNS doesn't work either, which creates secondary problems. I test strictly IP connectivity with ssh: $ ssh user@172.31.63.211 If the VPN connection is up, this fails. If I bring down the connection (ipsec down vpn), SSH works. Can someone please help? Prior VPN solutions I've used set up a brand new interface, so I'm really stuck. I tried changing rightsubnet to 10.0.0.0/8 (the IP range of the VPN), but VPN connectivity fails altogether. Other ideas I have for a solution include inserting something into the routing table, or getting Strongswan to somehow create its own network interface, but I'm not sure. I'd appreciate some guidance towards a solution. Alan ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Throughput on high BDP networks
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello John, It is likely that that is caused by insufficient crypto processing capabilities on either side, so packets need to be dropped, as the transmit/receive buffers are full. A solution to this problem is to distribute the work load over several kernels using pcrypt[1]. [1] https://wiki.strongswan.org/projects/strongswan/wiki/Pcrypt Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 23:57 schrieb jsulli...@opensourcedevel.com: Hello, all. We are attempting to use StrongSWAN on a fast (1 Gbps CIR one side and 4x10Gbps on the other) with about 80ms latency so pretty high bandwidth delay product. The traffic is GRE/IPSec. Our benchmarks show we can saturate the 1 Gbps side with just GRE sustaining high 800 low 900 Mbps. When we activate IPSec, we plummet to around 40 Mbps - maybe we'll hit 400 Mbps on occasion. This seems to be a TCP windowing problem provoked by TCP segment retransmissions. When we use nstat between runs, GRE shows virtually no segment retransmissions where GRE/IPSec shows thousands. GRE tunnel MTU is 1412 so it should be fine for both transport and tunnel mode. sanitized config is: type=transport esp=aes128gcm8-modp1024 leftprotoport=47 rightprotoport=47 dpddelay=9 dpdtimeout=30 compress=yes keyingtries=20 keylife=60m rekeymargin=5m ikelifetime=3h mobike=no authby=rsasig rightrsasigkey=%cert nat_traversal=yes charonstart=yes plutostart=yes We are using intel cards with igb on one side and ixgbe on the other. What do we need to do to eliminate the lost packets and where can we see the drops? I don't see them on any queues, qdiscs - no stats showing packet drops. Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVajNHAAoJEDg5KY9j7GZYv0sQAJB1ZDJvO5JWQ1jaAyexe1fk YwvugHH7FAY6mQH0glVct2Ro1+/c0hRCHgnjIKF6ICQkz6GxcHxbJzr+fnGON31c faoIVgCm4gxCjHR6Tcj1DMC8I6vDeUJ7nM7rGqs1XXN/+H3vLD+KRK9p0RC3mn85 jc1HWCdyDjdjiNEO7ENi6SUYFkYnuiBIcmbroTcIP+FVvnWd/DHAUKSCxGedVTeO 0izwkKwGPw9bYkBk2l1Q9K+jccpFoyBzFeMKHnrTQ+hzC46qCGbXNmJklVg9vlHX H6BszfBdKAiDQ5SOaMe955f8RVynWpktZ2FpistfBylrnCyVfBVsDQXXF9BT9287 tUsVfGbeA+4rCVrlLb/wiciqFLCP95bxITCaxW+3cYEYxNnr1wn5I2MRFRWeJrQL /HVrWtPqcWTFC+G7kt0XfmMdhsCtIURRt1q0k0ULTqVpALXRbJ+ksFR+zS7X1Hiy h9wy9jpa4v13Yg8vdOFofn6pe/Dv9/SNnLwfzJpmdit9U4A4QW2C/hZB31EmkuLK GSTCAZguAKnu/QOlN2zUqRLsAVpb4QlnqLqLJkvbnvooJu80OI7t95asutf5B+9i 3JAunbtHSlci//uYl59/6lvgfFFKvXNxVH9YMsbS+G2Cn0RIQzj6e0ZdSNXFwRxy 877iMnpvaZdPPlNZ0r6g =vgw7 -END PGP SIGNATURE- ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
[strongSwan] Throughput on high BDP networks
Hello, all. We are attempting to use StrongSWAN on a fast (1 Gbps CIR one side and 4x10Gbps on the other) with about 80ms latency so pretty high bandwidth delay product. The traffic is GRE/IPSec. Our benchmarks show we can saturate the 1 Gbps side with just GRE sustaining high 800 low 900 Mbps. When we activate IPSec, we plummet to around 40 Mbps - maybe we'll hit 400 Mbps on occasion. This seems to be a TCP windowing problem provoked by TCP segment retransmissions. When we use nstat between runs, GRE shows virtually no segment retransmissions where GRE/IPSec shows thousands. GRE tunnel MTU is 1412 so it should be fine for both transport and tunnel mode. sanitized config is: type=transport esp=aes128gcm8-modp1024 leftprotoport=47 rightprotoport=47 dpddelay=9 dpdtimeout=30 compress=yes keyingtries=20 keylife=60m rekeymargin=5m ikelifetime=3h mobike=no authby=rsasig rightrsasigkey=%cert nat_traversal=yes charonstart=yes plutostart=yes We are using intel cards with igb on one side and ixgbe on the other. What do we need to do to eliminate the lost packets and where can we see the drops? I don't see them on any queues, qdiscs - no stats showing packet drops. Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Throughput on high BDP networks
On May 30, 2015 at 6:01 PM Noel Kuntze n...@familie-kuntze.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello John, It is likely that that is caused by insufficient crypto processing capabilities on either side, so packets need to be dropped, as the transmit/receive buffers are full. A solution to this problem is to distribute the work load over several kernels using pcrypt[1]. [1] https://wiki.strongswan.org/projects/strongswan/wiki/Pcrypt Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 This looks like exactly what I need and I do see the dropped packets in ip -s link ls. However, I am utterly confused about what to use for the tcrypt options. I am using esp=aes128gcm8-modp1024 which I would think mean using the example given in the article, i.e., modprobe tcrypt alg=pcrypt(rfc4106(gcm(aes))) type=3 but I see no improvement with that even after re-establishing the tunnel (ipsec down then ipsec up). I'm guessing my way through /proc/crypto but am really only guessing. There doesn't seem to be a lot of information on using this. Any guidance would be appreciated - John Am 30.05.2015 um 23:57 schrieb jsulli...@opensourcedevel.com: Hello, all. We are attempting to use StrongSWAN on a fast (1 Gbps CIR one side and 4x10Gbps on the other) with about 80ms latency so pretty high bandwidth delay product. The traffic is GRE/IPSec. Our benchmarks show we can saturate the 1 Gbps side with just GRE sustaining high 800 low 900 Mbps. When we activate IPSec, we plummet to around 40 Mbps - maybe we'll hit 400 Mbps on occasion. This seems to be a TCP windowing problem provoked by TCP segment retransmissions. When we use nstat between runs, GRE shows virtually no segment retransmissions where GRE/IPSec shows thousands. GRE tunnel MTU is 1412 so it should be fine for both transport and tunnel mode. sanitized config is: type=transport esp=aes128gcm8-modp1024 leftprotoport=47 rightprotoport=47 dpddelay=9 dpdtimeout=30 compress=yes keyingtries=20 keylife=60m rekeymargin=5m ikelifetime=3h mobike=no authby=rsasig rightrsasigkey=%cert nat_traversal=yes charonstart=yes plutostart=yes We are using intel cards with igb on one side and ixgbe on the other. What do we need to do to eliminate the lost packets and where can we see the drops? I don't see them on any queues, qdiscs - no stats showing packet drops. Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVajNHAAoJEDg5KY9j7GZYv0sQAJB1ZDJvO5JWQ1jaAyexe1fk YwvugHH7FAY6mQH0glVct2Ro1+/c0hRCHgnjIKF6ICQkz6GxcHxbJzr+fnGON31c faoIVgCm4gxCjHR6Tcj1DMC8I6vDeUJ7nM7rGqs1XXN/+H3vLD+KRK9p0RC3mn85 jc1HWCdyDjdjiNEO7ENi6SUYFkYnuiBIcmbroTcIP+FVvnWd/DHAUKSCxGedVTeO 0izwkKwGPw9bYkBk2l1Q9K+jccpFoyBzFeMKHnrTQ+hzC46qCGbXNmJklVg9vlHX H6BszfBdKAiDQ5SOaMe955f8RVynWpktZ2FpistfBylrnCyVfBVsDQXXF9BT9287 tUsVfGbeA+4rCVrlLb/wiciqFLCP95bxITCaxW+3cYEYxNnr1wn5I2MRFRWeJrQL /HVrWtPqcWTFC+G7kt0XfmMdhsCtIURRt1q0k0ULTqVpALXRbJ+ksFR+zS7X1Hiy h9wy9jpa4v13Yg8vdOFofn6pe/Dv9/SNnLwfzJpmdit9U4A4QW2C/hZB31EmkuLK GSTCAZguAKnu/QOlN2zUqRLsAVpb4QlnqLqLJkvbnvooJu80OI7t95asutf5B+9i 3JAunbtHSlci//uYl59/6lvgfFFKvXNxVH9YMsbS+G2Cn0RIQzj6e0ZdSNXFwRxy 877iMnpvaZdPPlNZ0r6g =vgw7 -END PGP SIGNATURE- ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] Throughput on high BDP networks
On May 30, 2015 at 10:42 PM jsulli...@opensourcedevel.com jsulli...@opensourcedevel.com wrote: On May 30, 2015 at 6:01 PM Noel Kuntze n...@familie-kuntze.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello John, It is likely that that is caused by insufficient crypto processing capabilities on either side, so packets need to be dropped, as the transmit/receive buffers are full. A solution to this problem is to distribute the work load over several kernels using pcrypt[1]. [1] https://wiki.strongswan.org/projects/strongswan/wiki/Pcrypt Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 This looks like exactly what I need and I do see the dropped packets in ip -s link ls. However, I am utterly confused about what to use for the tcrypt options. I am using esp=aes128gcm8-modp1024 which I would think mean using the example given in the article, i.e., modprobe tcrypt alg=pcrypt(rfc4106(gcm(aes))) type=3 but I see no improvement with that even after re-establishing the tunnel (ipsec down then ipsec up). I'm guessing my way through /proc/crypto but am really only guessing. There doesn't seem to be a lot of information on using this. Any guidance would be appreciated - John I've been able to sort through with some guesswork and snooping through /proc/crypto (modprobe tcrypt alg=pcrypt(rfc4106-gcm-aesni) type=3) but the results are a little disappointing. I can see the multiple kworker threads spread across all 12 cores in these fairly high powered systems but I am still dropping packets and performance is not much improved. Any further suggestions? Thanks - John Am 30.05.2015 um 23:57 schrieb jsulli...@opensourcedevel.com: Hello, all. We are attempting to use StrongSWAN on a fast (1 Gbps CIR one side and 4x10Gbps on the other) with about 80ms latency so pretty high bandwidth delay product. The traffic is GRE/IPSec. Our benchmarks show we can saturate the 1 Gbps side with just GRE sustaining high 800 low 900 Mbps. When we activate IPSec, we plummet to around 40 Mbps - maybe we'll hit 400 Mbps on occasion. This seems to be a TCP windowing problem provoked by TCP segment retransmissions. When we use nstat between runs, GRE shows virtually no segment retransmissions where GRE/IPSec shows thousands. GRE tunnel MTU is 1412 so it should be fine for both transport and tunnel mode. sanitized config is: type=transport esp=aes128gcm8-modp1024 leftprotoport=47 rightprotoport=47 dpddelay=9 dpdtimeout=30 compress=yes keyingtries=20 keylife=60m rekeymargin=5m ikelifetime=3h mobike=no authby=rsasig rightrsasigkey=%cert nat_traversal=yes charonstart=yes plutostart=yes We are using intel cards with igb on one side and ixgbe on the other. What do we need to do to eliminate the lost packets and where can we see the drops? I don't see them on any queues, qdiscs - no stats showing packet drops. Thanks - John ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVajNHAAoJEDg5KY9j7GZYv0sQAJB1ZDJvO5JWQ1jaAyexe1fk YwvugHH7FAY6mQH0glVct2Ro1+/c0hRCHgnjIKF6ICQkz6GxcHxbJzr+fnGON31c faoIVgCm4gxCjHR6Tcj1DMC8I6vDeUJ7nM7rGqs1XXN/+H3vLD+KRK9p0RC3mn85 jc1HWCdyDjdjiNEO7ENi6SUYFkYnuiBIcmbroTcIP+FVvnWd/DHAUKSCxGedVTeO 0izwkKwGPw9bYkBk2l1Q9K+jccpFoyBzFeMKHnrTQ+hzC46qCGbXNmJklVg9vlHX H6BszfBdKAiDQ5SOaMe955f8RVynWpktZ2FpistfBylrnCyVfBVsDQXXF9BT9287 tUsVfGbeA+4rCVrlLb/wiciqFLCP95bxITCaxW+3cYEYxNnr1wn5I2MRFRWeJrQL /HVrWtPqcWTFC+G7kt0XfmMdhsCtIURRt1q0k0ULTqVpALXRbJ+ksFR+zS7X1Hiy h9wy9jpa4v13Yg8vdOFofn6pe/Dv9/SNnLwfzJpmdit9U4A4QW2C/hZB31EmkuLK GSTCAZguAKnu/QOlN2zUqRLsAVpb4QlnqLqLJkvbnvooJu80OI7t95asutf5B+9i 3JAunbtHSlci//uYl59/6lvgfFFKvXNxVH9YMsbS+G2Cn0RIQzj6e0ZdSNXFwRxy 877iMnpvaZdPPlNZ0r6g =vgw7 -END PGP SIGNATURE- ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
This route should be inserted in route table 220 发自我的 iPhone 在 2015年5月30日，14:00，Alan Tu 8li...@gmail.com 写道： Hmmm, I don't think this worked. The pre- and post-VPN routing tables are actually identical: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I then added a new route: # route add -net 172.31.48.0 netmask 255.255.240.0 gw 172.31.48.1 dev eth0 New routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 172.31.48.1 255.255.240.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I still couldn't SSH to 172.31.63.211 while the VPN tunnel is up. Alan On 5/30/15, Zhuyj mounter...@163.com wrote: Check route, 0.0.0.0 is not good, a specific LAN is better 发自我的 iPhone 在 2015年5月30日，7:58，Alan Tu 8li...@gmail.com 写道： Hello, I'm using Strongswan 5.3.0 to successfully connect a Linux machine to a VPN over the Internet. However, after I bring up the VPN tunnel, my client Linux machine cannot talk to other machines on its own LAN, even though it can talk to machines everywhere else on the Internet, as well as to machines on the VPN. Can someone give me a hint as to the solution? My client machine has IP address 172.31.59.36. The eth0 network interface has netmask /20. The pre-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_hostname. 0.0.0.0 UG0 00 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Post-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_ip 0.0.0.0 UG0 00 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Here are some potentially relevant lines from my ipsec.conf file: conn vpn type=tunnel aggressive=yes xauth=client left=%any leftid=keyid:... leftsourceip=%modeconfig right=[public IP of VPN gateway] rightsubnet=0.0.0.0/0 After the Strongswan VPN connection is brought up, and the virtual IP is inserted into eth0, I cannot access other machines in the 172.31.x.x range. The VPN virtual IP addresses are in the 10.0.0.0/8 range, so there is no apparent conflict. I think my root problem is something related to routing, but I don't know how to fix it. Because routing to local servers on the LAN no longer works, non-VPN DNS doesn't work either, which creates secondary problems. I test strictly IP connectivity with ssh: $ ssh user@172.31.63.211 If the VPN connection is up, this fails. If I bring down the connection (ipsec down vpn), SSH works. Can someone please help? Prior VPN solutions I've used set up a brand new interface, so I'm really stuck. I tried changing rightsubnet to 10.0.0.0/8 (the IP range of the VPN), but VPN connectivity fails altogether. Other ideas I have for a solution include inserting something into the routing table, or getting Strongswan to somehow create its own network interface, but I'm not sure. I'd appreciate some guidance towards a solution. Alan ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
Thanks Zhuyj and Noel, I am a bit more enlightened and closer. I'm still a little lost, working with the guts of Linux routing is quite new to me. Linux can have multiple routing tables, identified by a number. 220 is just the number chosen by Strongswan to insert its new route. route apparently just shows the main routing table. The better command is ip route: $ ip route show table 220 default via 172.31.48.1 dev eth0 proto static src 10.100.4.45 In this routing table 220, the default route is set to the Internet gateway, going out the ethernet interface eth0. 10.100.4.45 is the virtual IP address assigned by the VPN gateway, but I don't know what its presence in this output means. 1. Maybe I need a line in this routing table 220 that specifies the local subnet 172.31.48.0/20, without the virtual IP address at the end of the routing table entry. Some potentially relevant lines from my XFRM policies: # ip xfrm policy show src 0.0.0.0/0 dst 10.100.4.45/32 dir fwd priority 2947 tmpl src [public_VPN_gateway] dst 172.31.59.240 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.100.4.45/32 dir in priority 2947 tmpl src [public_VPN_gateway] dst 172.31.59.240 proto esp reqid 1 mode tunnel src 10.100.4.45/32 dst 0.0.0.0/0 dir out priority 2947 tmpl src 172.31.59.240 dst [public_VPN_gateway] proto esp reqid 1 mode tunnel ... It seems XFRM is the virtual IP magic that takes the ethernet eth0 packets, and sends the packets through the ipsec/Strongswan crypto system. 2. Maybe I need to specify a XFRM policy that says don't encrypt packets going to the LAN, specifically 172.31.48.0/20. Where I'm lost is, do I need remedy #1 or remedy #2, or both? I don't know yet how to do either remedy, so knowing what I should do would help my trial and error. Thanks. Alan On 5/30/15, Noel Kuntze n...@familie-kuntze.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, strongSwan builds policy based tunnels. XFRM policies are used to steal the packets from the kernel after the routing decision. You need to write a passthrough policy that matches the traffic in your LAN to except it from the policy of your tunnel. Routing table 220 only has routes, so the incoming traffic through the tunnel passes the reverse path filter. Look at those test scenarios, there they are called shunt policies. https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 09:41 schrieb Zhuyj: This route should be inserted in route table 220 发自我的 iPhone 在 2015年5月30日，14:00，Alan Tu 8li...@gmail.com 写道： Hmmm, I don't think this worked. The pre- and post-VPN routing tables are actually identical: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I then added a new route: # route add -net 172.31.48.0 netmask 255.255.240.0 gw 172.31.48.1 dev eth0 New routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 172.31.48.1 255.255.240.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I still couldn't SSH to 172.31.63.211 while the VPN tunnel is up. Alan On 5/30/15, Zhuyj mounter...@163.com wrote: Check route, 0.0.0.0 is not good, a specific LAN is better 发自我的 iPhone 在 2015年5月30日，7:58，Alan Tu 8li...@gmail.com 写道： Hello, I'm using Strongswan 5.3.0 to successfully connect a Linux machine to a VPN over the Internet. However, after I bring up the VPN tunnel, my client Linux machine cannot talk to other machines on its own LAN, even though it can talk to machines everywhere else on the Internet, as well as to machines on the VPN. Can someone give me a hint as to the solution? My client machine has IP address 172.31.59.36. The eth0 network interface has netmask /20. The pre-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_hostname. 0.0.0.0 UG0 0 0 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Post-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_ip 0.0.0.0 UG0 00 eth0 172.31.48.0 *
Re: [strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello, strongSwan builds policy based tunnels. XFRM policies are used to steal the packets from the kernel after the routing decision. You need to write a passthrough policy that matches the traffic in your LAN to except it from the policy of your tunnel. Routing table 220 only has routes, so the incoming traffic through the tunnel passes the reverse path filter. Look at those test scenarios, there they are called shunt policies. https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 09:41 schrieb Zhuyj: This route should be inserted in route table 220 发自我的 iPhone 在 2015年5月30日，14:00，Alan Tu 8li...@gmail.com 写道： Hmmm, I don't think this worked. The pre- and post-VPN routing tables are actually identical: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I then added a new route: # route add -net 172.31.48.0 netmask 255.255.240.0 gw 172.31.48.1 dev eth0 New routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 172.31.48.1 255.255.240.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I still couldn't SSH to 172.31.63.211 while the VPN tunnel is up. Alan On 5/30/15, Zhuyj mounter...@163.com wrote: Check route, 0.0.0.0 is not good, a specific LAN is better 发自我的 iPhone 在 2015年5月30日，7:58，Alan Tu 8li...@gmail.com 写道： Hello, I'm using Strongswan 5.3.0 to successfully connect a Linux machine to a VPN over the Internet. However, after I bring up the VPN tunnel, my client Linux machine cannot talk to other machines on its own LAN, even though it can talk to machines everywhere else on the Internet, as well as to machines on the VPN. Can someone give me a hint as to the solution? My client machine has IP address 172.31.59.36. The eth0 network interface has netmask /20. The pre-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_hostname. 0.0.0.0 UG0 00 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Post-VPN routing table: $ route Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface default gateway_ip 0.0.0.0 UG0 00 eth0 172.31.48.0 * 255.255.240.0 U 0 00 eth0 Here are some potentially relevant lines from my ipsec.conf file: conn vpn type=tunnel aggressive=yes xauth=client left=%any leftid=keyid:... leftsourceip=%modeconfig right=[public IP of VPN gateway] rightsubnet=0.0.0.0/0 After the Strongswan VPN connection is brought up, and the virtual IP is inserted into eth0, I cannot access other machines in the 172.31.x.x range. The VPN virtual IP addresses are in the 10.0.0.0/8 range, so there is no apparent conflict. I think my root problem is something related to routing, but I don't know how to fix it. Because routing to local servers on the LAN no longer works, non-VPN DNS doesn't work either, which creates secondary problems. I test strictly IP connectivity with ssh: $ ssh user@172.31.63.211 If the VPN connection is up, this fails. If I bring down the connection (ipsec down vpn), SSH works. Can someone please help? Prior VPN solutions I've used set up a brand new interface, so I'm really stuck. I tried changing rightsubnet to 10.0.0.0/8 (the IP range of the VPN), but VPN connectivity fails altogether. Other ideas I have for a solution include inserting something into the routing table, or getting Strongswan to somehow create its own network interface, but I'm not sure. I'd appreciate some guidance towards a solution. Alan ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJVaZPQAAoJEDg5KY9j7GZYRPkP/1IvFes+6lxoMauwK+M6KAtV HkbbpL9OxXpQn1Ly53YOS67oCuHF8/JBMfh8F68zgixCkMQCzYeGxPFr6+3AhdcT nuS88r5ADJLA4NNidN4S7ehi7FZsT79RcxNXTKEalAMs7MBxM/XRfS7VoigG8p4p
Re: [strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Alan, Remedy #2 is your salvation. The ipsec.conf files of the test scenarios I linked to have example passthrough policy definitions. Look at those. I think things will be much clearer then. Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 15:01 schrieb Alan Tu: Thanks Zhuyj and Noel, I am a bit more enlightened and closer. I'm still a little lost, working with the guts of Linux routing is quite new to me. Linux can have multiple routing tables, identified by a number. 220 is just the number chosen by Strongswan to insert its new route. route apparently just shows the main routing table. The better command is ip route: $ ip route show table 220 default via 172.31.48.1 dev eth0 proto static src 10.100.4.45 In this routing table 220, the default route is set to the Internet gateway, going out the ethernet interface eth0. 10.100.4.45 is the virtual IP address assigned by the VPN gateway, but I don't know what its presence in this output means. 1. Maybe I need a line in this routing table 220 that specifies the local subnet 172.31.48.0/20, without the virtual IP address at the end of the routing table entry. Some potentially relevant lines from my XFRM policies: # ip xfrm policy show src 0.0.0.0/0 dst 10.100.4.45/32 dir fwd priority 2947 tmpl src [public_VPN_gateway] dst 172.31.59.240 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.100.4.45/32 dir in priority 2947 tmpl src [public_VPN_gateway] dst 172.31.59.240 proto esp reqid 1 mode tunnel src 10.100.4.45/32 dst 0.0.0.0/0 dir out priority 2947 tmpl src 172.31.59.240 dst [public_VPN_gateway] proto esp reqid 1 mode tunnel ... It seems XFRM is the virtual IP magic that takes the ethernet eth0 packets, and sends the packets through the ipsec/Strongswan crypto system. 2. Maybe I need to specify a XFRM policy that says don't encrypt packets going to the LAN, specifically 172.31.48.0/20. Where I'm lost is, do I need remedy #1 or remedy #2, or both? I don't know yet how to do either remedy, so knowing what I should do would help my trial and error. Thanks. Alan On 5/30/15, Noel Kuntze n...@familie-kuntze.de wrote: Hello, strongSwan builds policy based tunnels. XFRM policies are used to steal the packets from the kernel after the routing decision. You need to write a passthrough policy that matches the traffic in your LAN to except it from the policy of your tunnel. Routing table 220 only has routes, so the incoming traffic through the tunnel passes the reverse path filter. Look at those test scenarios, there they are called shunt policies. https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 09:41 schrieb Zhuyj: This route should be inserted in route table 220 发自我的 iPhone 在 2015年5月30日，14:00，Alan Tu 8li...@gmail.com 写道： Hmmm, I don't think this worked. The pre- and post-VPN routing tables are actually identical: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I then added a new route: # route add -net 172.31.48.0 netmask 255.255.240.0 gw 172.31.48.1 dev eth0 New routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 00 eth0 172.31.48.0 172.31.48.1 255.255.240.0 UG0 00 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 00 eth0 I still couldn't SSH to 172.31.63.211 while the VPN tunnel is up. Alan On 5/30/15, Zhuyj mounter...@163.com wrote: Check route, 0.0.0.0 is not good, a specific LAN is better 发自我的 iPhone 在 2015年5月30日，7:58，Alan Tu 8li...@gmail.com 写道： Hello, I'm using Strongswan 5.3.0 to successfully connect a Linux machine to a VPN over the Internet. However, after I bring up the VPN tunnel, my client Linux machine cannot talk to other machines on its own LAN, even though it can talk to machines everywhere else on the Internet, as well as to machines on the VPN. Can someone give me a hint as to the solution? My client machine has IP address 172.31.59.36. The eth0 network interface has netmask /20. The pre-VPN routing table: $ route Kernel IP routing table Destination Gateway
Re: [strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
It works! Thank you Noel! The key is to set up a pass-through connection in Strongswan's own ipsec.conf configuration file. No mucking with Linux kernel routing or XFRM policy guts needed. conn my_precious_lan leftsubnet=172.31.0.0/16 rightsubnet=172.31.0.0/16 authby=never type=passthrough auto=route This pass-through connection will be activated the first time its needed. Alan On 5/30/15, Noel Kuntze n...@familie-kuntze.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hello Alan, Remedy #2 is your salvation. The ipsec.conf files of the test scenarios I linked to have example passthrough policy definitions. Look at those. I think things will be much clearer then. Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 15:01 schrieb Alan Tu: Thanks Zhuyj and Noel, I am a bit more enlightened and closer. I'm still a little lost, working with the guts of Linux routing is quite new to me. Linux can have multiple routing tables, identified by a number. 220 is just the number chosen by Strongswan to insert its new route. route apparently just shows the main routing table. The better command is ip route: $ ip route show table 220 default via 172.31.48.1 dev eth0 proto static src 10.100.4.45 In this routing table 220, the default route is set to the Internet gateway, going out the ethernet interface eth0. 10.100.4.45 is the virtual IP address assigned by the VPN gateway, but I don't know what its presence in this output means. 1. Maybe I need a line in this routing table 220 that specifies the local subnet 172.31.48.0/20, without the virtual IP address at the end of the routing table entry. Some potentially relevant lines from my XFRM policies: # ip xfrm policy show src 0.0.0.0/0 dst 10.100.4.45/32 dir fwd priority 2947 tmpl src [public_VPN_gateway] dst 172.31.59.240 proto esp reqid 1 mode tunnel src 0.0.0.0/0 dst 10.100.4.45/32 dir in priority 2947 tmpl src [public_VPN_gateway] dst 172.31.59.240 proto esp reqid 1 mode tunnel src 10.100.4.45/32 dst 0.0.0.0/0 dir out priority 2947 tmpl src 172.31.59.240 dst [public_VPN_gateway] proto esp reqid 1 mode tunnel ... It seems XFRM is the virtual IP magic that takes the ethernet eth0 packets, and sends the packets through the ipsec/Strongswan crypto system. 2. Maybe I need to specify a XFRM policy that says don't encrypt packets going to the LAN, specifically 172.31.48.0/20. Where I'm lost is, do I need remedy #1 or remedy #2, or both? I don't know yet how to do either remedy, so knowing what I should do would help my trial and error. Thanks. Alan On 5/30/15, Noel Kuntze n...@familie-kuntze.de wrote: Hello, strongSwan builds policy based tunnels. XFRM policies are used to steal the packets from the kernel after the routing decision. You need to write a passthrough policy that matches the traffic in your LAN to except it from the policy of your tunnel. Routing table 220 only has routes, so the incoming traffic through the tunnel passes the reverse path filter. Look at those test scenarios, there they are called shunt policies. https://www.strongswan.org/uml/testresults/ikev2/shunt-policies-nat-rw/index.html https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/index.html Mit freundlichen Grüßen/Kind Regards, Noel Kuntze GPG Key ID: 0x63EC6658 Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658 Am 30.05.2015 um 09:41 schrieb Zhuyj: This route should be inserted in route table 220 发自我的 iPhone 在 2015年5月30日，14:00，Alan Tu 8li...@gmail.com 写道： Hmmm, I don't think this worked. The pre- and post-VPN routing tables are actually identical: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 0 0 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 I then added a new route: # route add -net 172.31.48.0 netmask 255.255.240.0 gw 172.31.48.1 dev eth0 New routing table: $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 172.31.48.1 0.0.0.0 UG0 0 0 eth0 172.31.48.0 172.31.48.1 255.255.240.0 UG0 0 0 eth0 172.31.48.0 0.0.0.0 255.255.240.0 U 0 0 0 eth0 I still couldn't SSH to 172.31.63.211 while the VPN tunnel is up. Alan On 5/30/15, Zhuyj mounter...@163.com wrote: Check route, 0.0.0.0 is not good, a specific LAN is better 发自我的 iPhone 在 2015年5月30日，7:58，Alan Tu 8li...@gmail.com 写道： Hello, I'm using Strongswan 5.3.0 to successfully connect a Linux machine to a VPN over the Internet. However, after I bring
[strongSwan] closeaction
Hello, I just thought I'd point out that the documentation for ipsec.conf seems to be incorrect. Either that or I'm mis-reading it. It suggests that closeaction is only applicable to IKEv2. However, I've been testing it with IKEv1 using the hold action in the event that the peer sends a delete for the IKE SA due to idle timeout being reached. The connection is deleted but is listed under routed connections. When I comment out closeaction, the connection is deleted and not listed under routed connections. https://wiki.strongswan.org/projects/strongswan/wiki/ConnSection closeaction = none | clear | hold | restart defines the action to take if the remote peer unexpectedly closes a CHILD_SA (IKEv2 only, see dpdaction for meaning of values). A closeaction should not be used if the peer uses reauthentication or uniqueids checking, as these events might trigger the defined action when not desired. Regards, Tormod Please consider the environment before printing this email * This e-mail and any attachments are confidential. If it is not for you, please inform us and delete it immediately without disclosing, copying, or distributing it. If the content is not about the business of PayWizard Group PLC or its clients, then it is neither from nor sanctioned by PayWizard Group PLC. Use of this or any other PayWizard Group PLC e-mail facility signifies consent to interception by PayWizard Group PLC. The views expressed in this email or any attachments may not reflect the views and opinions of PayWizard Group PLC. This message has been scanned for viruses and dangerous content by MailScanner, but PayWizard Group PLC accepts no liability for any damage caused by the transmission of any viruses. PayWizard Group PLC is a public limited company registered in Scotland (SC175703) with its registered office at Cluny Court, John Smith Business Park, Kirkcaldy, Fife, KY2 6QJ. ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
Re: [strongSwan] charon crash on Mac OS X 10.9 with IPv6 Virtual IP
I can confirm this bug on strongSwan 5.3.0 from Homebrew and OSX 10.10.3 Submited new bug report https://wiki.strongswan.org/issues/974 ___ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users
