[strongSwan] client machine cannot talk to local LAN if VPN tunnel over the Internet is connected

Sun Jul 12 16:46:34 CEST 2015

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi,

what does "This pass-through connection will be activated the first
time its needed." exactly mean? I put a similar entry into my
ipsec.conf on my local gateway (just a different IP range) but the
passthrough routes are never activated.
Only when I connect back over the VPN to my local gateway and set the
policies manually by entering

ip xfrm policy add src 172.31.0.0/16 dst 172.31.0.0/16 proto any dir
in ptype main priority 1500
ip xfrm policy add src 172.31.0.0/16 dst 172.31.0.0/16 proto any dir
out ptype main priority 1500

the routes are set and I can reach the gw on it's local address again.

kind regards
Ingmar Rosenhagen

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 <noel at 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 <noel at 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/i
ndex.html
>> 
https://www.strongswan.org/uml/testresults/sql/shunt-policies-nat-rw/ind
ex.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
>> 
>>> 
>>> 
>>> _______________________________________________ Users mailing
>>> list Users at 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-----
> 
> 
- -- 
Looking for a Signature? Why not Zoidberg?
	(\/)_(;,,;)_(\/)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVon3KAAoJEB0r3iflYJCarAYP/29KJ5G89rPyJRxuc0iOycJw
MzbPFVFoF7YLiHIBpf+mX7OQcRP8vLExtXFDRGkAKhocqo6ozRez5+LsVpJbhEuj
/2CXX8RZTejluNzp4OJsmmg+GFjV4n06DiKTzhi3U1wWgmQE/GaZlBeZ7ipcNZgt
4ChAz+34m92LnzipjeLwlZogIcSmCpckGCbSq5efv+1kcZoOTyBCh7JhNxOnndvJ
sWQk7stjrQNvXeBuP5JaSMZp7cD2oCHE/XfezuB7filg3tzr3KsG3EWsiOshrmMM
hKhPApu2hScfIcr7e/ETUw4lNCsNQ0fSmtwXx/BfANuk03sgzfFToWbOs4vq8ACs
+iRSQ+wZokIFQIVu9ouo61gl03fqnUthGWhv009CsdQ9Hqvw8ZDqL5/tF/WuNnC7
epl87VYlXfVbHwfax5aXXZ5wUbSgLetnbBj4FwDZKmrM3cKfFNtdF+bo9pHXTidP
CHZWZhftEJmUTCBOIIzpyteBIKBGFaX+cqkRL3zN3Qb5IlqNpZEsP9XEojLyx+Jl
sX3Ra1p6rm4A2eb7PE2/7dNtVeiisE6fFhKt/oxRvTui+lrgHim/woz1S3sWrBMs
jT3G8Ve+W7Di7w5teO/mQmKF0WpQ/oyYny3IbSQJudGdsnJXSLgOxSm9CKgOnDE4
QguEsxGnUUVHckyVBnO7
=jGo7
-----END PGP SIGNATURE-----