networkmanager-strongswan vpn - routing specific ip through VPN

Question

I'm trying to setting a VPN on Linux Mint 19.2.

I'm using the network-manager-strongswan so I added this file named VPN under /etc/NetworkManager/system-connections/

[connection]
id=VPN
uuid=be1d4fd1-bbaa-4aa9-9fdc-e293bf16fe67
type=vpn
autoconnect=false
permissions=
timestamp=1582680217

[vpn]
address=vpn********.it
certificate=
encap=yes
ipcomp=no
method=eap
password-flags=0
proposal=no
user=user
virtual=yes
service-type=org.freedesktop.NetworkManager.strongswan

[vpn-secrets]
password=password

[ipv4]
dns-search=
ignore-auto-dns=true
ignore-auto-routes=true
method=auto

[ipv6]
addr-gen-mode=stable-privacy
dns-search=
ip6-privacy=0
method=ignore

The connection is fine, I can access using ssh on the private network. The big issue is that after the connection I can't surf the internet, connecting to the vpn lock all other addresses.
I added the ignore-auto-routes flag in the config so why my connection is locked?

ip a output*

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:3c:de:1b brd ff:ff:ff:ff:ff:ff
    inet yy.16.209.132/24 brd yy.16.209.255 scope global dynamic noprefixroute ens33
       valid_lft 1656sec preferred_lft 1656sec
    inet yy.26.199.18/32 scope global ens33
       valid_lft forever preferred_lft forever
    inet6 fe80::216e:bcc0:3b4f:44b2/64 scope link noprefixroute 
       valid_lft forever preferred_lft forever

route -n output

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         yy.16.209.2    0.0.0.0         UG    20100  0        0 ens33
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 ens33
yy.16.209.0    0.0.0.0         255.255.255.0   U     100    0        0 ens33
yy.26.199.18   0.0.0.0         255.255.255.255 UH    50     0        0 ens33
yy.26.199.18   0.0.0.0         255.255.255.255 UH    100    0        0 ens33

ip xfrm policy output NO VPN

src yy.16.209.0/24 dst yy.16.209.0/24 
    dir fwd priority 175423 
src yy.16.209.0/24 dst yy.16.209.0/24 
    dir in priority 175423 
src yy.16.209.0/24 dst yy.16.209.0/24 
    dir out priority 175423 
src 169.254.0.0/16 dst 169.254.0.0/16 
    dir fwd priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
    dir in priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
    dir out priority 183615 
src fe80::/64 dst fe80::/64 
    dir fwd priority 134463 
src fe80::/64 dst fe80::/64 
    dir in priority 134463 
src fe80::/64 dst fe80::/64 
    dir out priority 134463 
src yy.26.199.18/32 dst 0.0.0.0/0 
    dir out priority 383615 
    tmpl src yy.16.209.132 dst xx.xx.124.58
        proto esp spi 0xc57cfb3f reqid 7 mode tunnel
src 0.0.0.0/0 dst yy.26.199.18/32 
    dir fwd priority 383615 
    tmpl src xx.xx.124.58 dst yy.16.209.132
        proto esp reqid 7 mode tunnel
src 0.0.0.0/0 dst yy.26.199.18/32 
    dir in priority 383615 
    tmpl src xx.xx.124.58 dst yy.16.209.132
        proto esp reqid 7 mode tunnel
src ::1/128 dst ::1/128 
    dir fwd priority 68927 
src ::1/128 dst ::1/128 
    dir in priority 68927 
src ::1/128 dst ::1/128 
    dir out priority 68927 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0

ip xfrm policy output UNDER VPN

src yy.26.199.18/32 dst 0.0.0.0/0 
    dir out priority 383615 
    tmpl src yy.16.209.132 dst xx.xx.124.58
        proto esp spi 0xc787ea42 reqid 2 mode tunnel
src 0.0.0.0/0 dst yy.26.199.18/32 
    dir fwd priority 383615 
    tmpl src xx.xx.124.58 dst yy.16.209.132
        proto esp reqid 2 mode tunnel
src 0.0.0.0/0 dst yy.26.199.18/32 
    dir in priority 383615 
    tmpl src xx.xx.124.58 dst yy.16.209.132
        proto esp reqid 2 mode tunnel
src fe80::/64 dst fe80::/64 
    dir fwd priority 134463 
src fe80::/64 dst fe80::/64 
    dir in priority 134463 
src fe80::/64 dst fe80::/64 
    dir out priority 134463 
src ::1/128 dst ::1/128 
    dir fwd priority 68927 
src ::1/128 dst ::1/128 
    dir in priority 68927 
src ::1/128 dst ::1/128 
    dir out priority 68927 
src yy.16.209.0/24 dst yy.16.209.0/24 
    dir fwd priority 175423 
src yy.16.209.0/24 dst yy.16.209.0/24 
    dir in priority 175423 
src yy.16.209.0/24 dst yy.16.209.0/24 
    dir out priority 175423 
src 169.254.0.0/16 dst 169.254.0.0/16 
    dir fwd priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
    dir in priority 183615 
src 169.254.0.0/16 dst 169.254.0.0/16 
    dir out priority 183615 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket in priority 0 
src 0.0.0.0/0 dst 0.0.0.0/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0 
src ::/0 dst ::/0 
    socket in priority 0 
src ::/0 dst ::/0 
    socket out priority 0

Diffing the outputs I can see this piece is added while the VPN is connected:

src yy.26.199.18/32 dst 0.0.0.0/0 
    dir out priority 383615 
    tmpl src yy.16.209.132 dst xx.xx.124.58
        proto esp spi 0xc787ea42 reqid 2 mode tunnel
src 0.0.0.0/0 dst yy.26.199.18/32 
    dir fwd priority 383615 
    tmpl src xx.xx.124.58 dst yy.16.209.132
        proto esp reqid 2 mode tunnel
src 0.0.0.0/0 dst yy.26.199.18/32 
    dir in priority 383615 
    tmpl src xx.xx.124.58 dst yy.16.209.132
        proto esp reqid 2 mode tunnel

I tried a lot of things but with no luck.

tried to increase the Metric for yy.26.199.18 to 1050 and 1100.
route del default && ip route add default via yy.26.199.18 dev ens33
Tried to delete the route entries yy.26.199.18 but nothing changes

and a lot of others stupid stuff.

So I want to use my connection for the "normal internet" while routing specific addresses through VPN.
It is possible?

Does the remote machine know how to handle your traffic? Also - `tcpdump` is your friend. — Konrad Gajewski, Mar 29 '20 at 22:48
Don't know hot it's configured... I cant't access it! Yes I used tcpdump to inspect the traffic but I didn't figure out how to solve the problem! I'm relaively new to networking :) — Roberto Manfreda, Mar 30 '20 at 12:03

Gerrit · Accepted Answer · 2020-04-01T15:36:54.313

In the present state of charon-nm there is no 'setting' to define the remote network at the other end of the tunnel. The VPN client by default proposes the full address space and depends on the VPN responder to narrow the traffic selector down to a more specific remote subnet or subnets. You can see this in the Charon-nm code. And it is also mentioned in the Strongswan wiki for the NetworkManager plugin.

As you can see, there is no subnet configuration for the tunnel. We let the server administration choose the subnet(s); the client always proposes 0.0.0.0/0 for the remote network and the server narrows that down to the configured subnet(s).

So, if the responder doesn't narrow that down, then all unicast traffic leaving the host will be directed into the tunnel.

However there is a routing way out of this, provided that the VPN responder assigns a virtual IP. This is attached to the outer interface by charon-nm. This is requested by the virtual=yes setting. From the given data it is the second address on your external interface.

Strongswan by default uses a routing table id 220 and routing policy rule with priority 220 calling that table. This table actually sets the source of packets destined for VPN to the virtual IP on your side, and then they are caught by the xfrm policy rules. So you can bypass these rules with lower (as in executing earlier) priority rules and avoid the match with the xfrm policies.

For example if you want only traffic to 192.168.0.1/16 to enter the tunnel:

ip rule add from all to 192.168.0.1/16 table 220 priority 218
ip rule add table main priority 219

The first rule captures your 'wanted' traffic and sends it to the Strongswan table, the second rule skips the Strongswan table to the main table (this is where you add routes if you do not specify a table).

Or with a single negative rule:

ip rule add not from all to 192.168.0.1/16 table main priority 128

You can automate adding and deleting such rules with the network hooks in /etc/NetworkManager/dispatcher.d/ inside ./pre-up.d/ and ./pre-down.d/, just put executable scripts there with mode 0755 owned by 'root'. $2 will contain vpn-pre-up or vpn-pre-down respectively. $1 will contain the name of the outside interface. $CONNECTION_FILENAME will be the path /etc/NetworkManager/system-connections/yourfilename.

For example:

#!/bin/bash
if [[ "$2" == "vpn-pre-up" ]]
then
  ip rule ...
fi

To see if the route to a certain address doesn't come from table 220

ip route get address/32

You should ñot see a table 220 if it doesn't go through VPN and otherwise you would. Also the VPN route shows the virtual IP as src and the 'main' table shows the normal outside IP as src.

Showing rules in table 220:

ip route show table 220

When repeatedly changing settings in the VPN or in routing tables it can be useful to flush the cached routes:

ip route flush cache

It is also good to know perhaps, that bringing the VPN up will also cut off already running IP layer communication that is running in 'plain text' that should go through VPN. But if a VPN connection with full address space traffic selection opens BEFORE you bypass the route this also means that you will loose all running TCP connections at that time. Even though NetworkManager dispatcher calls its hook pre-up, the ip xfrm rules and route in table 220 is already up when the pre-up scripts are called, so this is something you need to consider and maybe set the route bypass of table 220 at boot time.

Tjank you for your time, I'll give a try tonight.. Anyway I posted the same question here https://unix.stackexchange.com/questions/571602/networkmanager-strongswan-vpn-routing-specific-ip-through-vpn/571723?noredirect=1#comment1069563_571723 . I'll let you know — Roberto Manfreda, Mar 30 '20 at 12:05
I tried it! It works very well... I was using another solution but it's literally the best way!! Thanks again for your time and effort! Here's your bounty :) — Roberto Manfreda, Mar 30 '20 at 16:14
Sorry can't upvote the answer for now, need reputation 15 :) — Roberto Manfreda, Mar 30 '20 at 16:15
Glad I could help. :-) I added a NetworkManager dispatcher example. See also https://developer.gnome.org/NetworkManager/stable/NetworkManager.html — Gerrit, Mar 30 '20 at 21:03

networkmanager-strongswan vpn - routing specific ip through VPN

1 Answers1