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

Mon Jul 13 00:49:06 CEST 2015

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

Hello Ingmar,

> what does "This pass-through connection will be activated the first
> time its needed." exactly mean?
That's wrong. The conn installs XFRM policies which tell the kernel subsystem to
not do any processing on the matching packets. Those policies are inserted directly after
charon parsed the config file.

> 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.
Make sure you don't have any stuff in conn %default. That might screw things up.

If you want any further help, show us your ipsec.conf

Mit freundlichen Grüßen/Kind Regards,
Noel Kuntze

GPG Key ID: 0x63EC6658
Fingerprint: 23CA BB60 2146 05E7 7278 6592 3839 298F 63EC 6658

Am 12.07.2015 um 16:46 schrieb Ingmar Rosenhagen:
> 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
>
> >
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJVou7bAAoJEDg5KY9j7GZYYzEQAJ8KicMBY58cAIqBDve6+1/P
dWsYacJ/KeqHsKnAZ1ybp/waTkfZ18sqTnnhx8T7zBQ2D5XtPlQFUzx84d6GECiP
O4AQyTea/C+8sSpU756TPjAzB6GF+yCqBV35BPhmoJQf7qrYF/YlhQcAW7ol5nFv
6AG3j7MbdV/gerSBOGQT92fyu/jMkACWvoBi3gimJwOGBxydhAxWA3mwOU448RH3
aXZQMWZXHj/qfgSMGyfJSQkjo5Y4QqeeBhmHCj8fan/7ygQ/V/fdUsyW8ALFZl67
+DeBqgvb0J5XUPKhb49Mcu6fcCqEWlEF0jzssBfz65E6La6oY4sLcitADC63/uhL
YJFeRVCmIwJUsLAq7NEbIWN6Rxg5hjr6bUTIn4cVHNqicYp82BYUEwelW721fcfV
q69IZddgYX/cQ00/R/PpPmOcAwDpjk7FOPbCuIvyKkfYA2wGRk3TSHCH5VIx6Nv7
eUfF4sqle7xg3opkm6iGZAwYnCJIxY+YNwIXpFyab2iZ7EgOCBsxwrTAjeYcuWuW
kPb4ebnhyTdVBxftecVXLB4jUKmRbRSz+pDHOrOECQMbW8qewtqwHG9mVa0SogqZ
Vdw5ZWc/cmlZmTURwJmHcnNUyT8+cKFJxPYoYuoGeGF4oHCe5OZ2z0bT7TF+/Jm+
xEDmv3R3qjFpfzXJDHZx
=6gUJ
-----END PGP SIGNATURE-----