-----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 UG 0 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 UG 0 0 0 > >>>> eth0 > >>>> 172.31.48.0 172.31.48.1 255.255.240.0 UG 0 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 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 Ref Use > >>>>>> Iface > >>>>>> default gateway_hostname. 0.0.0.0 UG 0 0 > >>>>>> 0 > >>>>>> eth0 > >>>>>> 172.31.48.0 * 255.255.240.0 U 0 0 0 > >>>>>> eth0 > >>>>>> > >>>>>> Post-VPN routing table: > >>>>>> $ route > >>>>>> Kernel IP routing table > >>>>>> Destination Gateway Genmask Flags Metric Ref Use > >>>>>> Iface > >>>>>> default gateway_ip 0.0.0.0 UG 0 0 0 > >>>>>> eth0 > >>>>>> 172.31.48.0 * 255.255.240.0 U 0 0 0 > >>>>>> 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 > >> >> >> _______________________________________________ >> Users mailing list >> Users@lists.strongswan.org >> https://lists.strongswan.org/mailman/listinfo/users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVabT2AAoJEDg5KY9j7GZYaBAP/3BIq64HKTrud2CGiE3qyV++ t16UEJyPhGlyv6MQdRGkmEwJDQz8681yfx9y8pcqCPGurI2MTzmRvRaKOBppESmt YcBznghXdUA5COx98l4w1TX2LlAElOTuLxqe/dw3BsL0bWPVW+Rg8WS9s4FCtlqP btoBGG8XOhYSEsHNtyTXuz1vG7R0TqNt/GtpYlSSWgBXhRCob/wxXUZ922RMpTse 1XqNsdpcqPWi4HHrsshjuT9B/nZ0Z8Q4WeaTwxW1oYU7NG0N+CIUPvzlWwaRz+UY 8IhKSW0bxkjR+d5D640xijYw44xDSfUp6fdrPl82IkaIkSR/1/oCu6AoVzl6F+jy V/iBffpQErx3gM8qYK4gnGOHwT/iixYgERQTNrCyKf3ebquUxV0l960Rd1jrddoY sZacyPyH5l4rwqU4wK/7l4GkER5Q5pdbqo3wPb2EdmFxYX1paRhvWit6/pQc+DDk z1v3ft1aBAeVCP5ZnwdhN3P9uFu5/U2EFGhZWcLYG61umpxFGrnV9M1jyFIb1IwW eV57hk/J+X1CbIc+T1QOwzS78NiVOC/YA58Z1yA2Ow65w21TdxydWYPQfdbVWPSV WbJoXDadPJHFncVWo8IPPNtii+DMIB0TIjAYS4cfOJXeefAnlWP9iGsW+FfzSeE+ E8d5pJ4UNuY7GqVDi0kc =fBkB -----END PGP SIGNATURE----- _______________________________________________ Users mailing list Users@lists.strongswan.org https://lists.strongswan.org/mailman/listinfo/users