[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 15:02:48 CEST 2015
-----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