-----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 <[email protected]> 写道： >> >> 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 <[email protected]> wrote: >>> Check route, 0.0.0.0 is not good, a specific LAN is better >>> >>> >>> 发自我的 iPhone >>> >>>> 在 2015年5月30日，7:58，Alan Tu <[email protected]> 写道： >>>> >>>> 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 [email protected] >>>> >>>> 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 >>>> [email protected] >>>> https://lists.strongswan.org/mailman/listinfo/users >>> >>> > > _______________________________________________ > Users mailing list > [email protected] > https://lists.strongswan.org/mailman/listinfo/users -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJVaZPQAAoJEDg5KY9j7GZYRPkP/1IvFes+6lxoMauwK+M6KAtV HkbbpL9OxXpQn1Ly53YOS67oCuHF8/JBMfh8F68zgixCkMQCzYeGxPFr6+3AhdcT nuS88r5ADJLA4NNidN4S7ehi7FZsT79RcxNXTKEalAMs7MBxM/XRfS7VoigG8p4p Cnczka1WuNa3SnZSmmpzGF6g/mcwdtrp3in6iH5iZdvVEI2YnoaL99AOFLpOBCEU rekFtzrMTHwULTatfOKfh9s2fJqUr4/o/h6va8kGbkWdL30jQD1e1BdZYKwX/l+3 s5XIAhUt6fKOSniNkkvTUJtZIR6xOnTfJlQFx9qvh45b20hXonaZVUYJNWjht5Ys 1SMuIW5mjIDI3/SyqP+ihc7HVmmApFLGW6aHpkOTrLZMmQwCACDQS7zSsQWyTkmJ hmc9rIwy860801Gn/lKo05sYCxeQKVmFQkiwdrfazC6Tbz4AfPum/FwYUOICTarH Au4yNmdmIHo2SU28oQ2vZtON3wGQuYVyPJuTwJAClZBvjLwp53z40YcllBXFU7QA 6dF+EM7BCWENy1tL1OKx6tKwdHsRhZMhatmqFcr2+JRUgtfj8ss0PHjc0zos1ijf yqSpp42a5csQhbg2Ad8lv6SPNfI6kz6TagtKt+ZIs2YAg5DoGXyCZLdqmxqOo95F EJ2ufa4GpXrIIrbM/3bs =fby3 -----END PGP SIGNATURE----- _______________________________________________ Users mailing list [email protected] https://lists.strongswan.org/mailman/listinfo/users
