[strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
Noel Kuntze
noel at familie-kuntze.de
Sat May 30 12:41:23 CEST 2015
-----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 <8libra at 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 <mounter625 at 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 <8libra at 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 at 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 at lists.strongswan.org
>>>> https://lists.strongswan.org/mailman/listinfo/users
>>>
>>>
>
> _______________________________________________
> Users mailing list
> Users at 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
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-----
More information about the Users
mailing list