[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:58:22 CEST 2015
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/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
>>
>>>
>>>
>>> _______________________________________________
>>> 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-----
>
>
More information about the Users
mailing list