[strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected
Alan Tu
8libra at gmail.com
Sat May 30 15:01:03 CEST 2015
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 <noel at 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 <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-----
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
More information about the Users
mailing list