Hi,

I have setup my VPN connection with KDE Network Manager (plasma-nm Version: 0.9.3.0-0ubuntu5) and it works perfectly. By default, it is setup to route all traffic over this interface.

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         *               0.0.0.0         U     0      0        0 ppp0
bioch-nts4.bioc 192.168.0.1     255.255.255.255 UGH   0      0        0 eth0
bioch-nts4.bioc 192.168.0.1     255.255.255.255 UGH   0      0        0 eth0
vpn6128.bioch.o *               255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     *               255.255.255.0   U     1      0        0 eth0

.

I am attempting to change this behaviour in order to route only traffic which is trying to access resources at my work to go over this interface, not all traffic. This seems easy, I check the 'Use only for resource on this connection' checkbox in the Edit IPv4 Routes dialogue. The default entry becomes:

Code: Select all

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         routerlogin.net 0.0.0.0         UG    0      0        0 eth0
129.67.72.248   routerlogin.net 255.255.255.255 UGH   0      0        0 eth0
129.67.72.248   routerlogin.net 255.255.255.255 UGH   0      0        0 eth0
129.67.76.128   *               255.255.255.255 UH    0      0        0 ppp0
192.168.0.0     *               255.255.255.0   U     1      0        0 eth0

Now, the VPN is correctly not used when I attempt to access resources (e.g. google.com) on the internet.

The Actual Problem:

The VPN does not get used when I attempt to use resources at work either. It behaves identically as if the VPN wasn't on at all.

Code: Select all

traceroute to micron3.bioch.ox.ac.uk (129.67.72.33), 30 hops max, 60 byte packets
 1  routerlogin.net (192.168.0.1)  0.583 ms  0.853 ms  1.281 ms
 2  cpc7-oxfd19-2-0-gw.4-3.cable.virginmedia.com (86.4.166.1)  13.397 ms  13.518 ms  14.379 ms
 3  oxfd-core-2b-ae6-722.network.virginmedia.net (213.106.245.201)  11.544 ms  13.039 ms  17.791 ms
 4  brnt-bb-1c-ae4-0.network.virginmedia.net (213.106.244.69)  21.821 ms  23.347 ms  23.489 ms
 5  brnt-bb-1a-ae11-0.network.virginmedia.net (62.253.174.29)  39.508 ms  23.171 ms  22.912 ms
 6  tclo-ic-2-ae0-0.network.virginmedia.net (212.250.14.202)  31.057 ms  22.848 ms  20.908 ms
 7  linx-gw2.ja.net (195.66.236.15)  22.117 ms  19.404 ms  17.750 ms
 8  ae1.londhx-sbr1.ja.net (146.97.35.173)  13.429 ms  15.002 ms  16.208 ms
 9  ae29.londpg-sbr1.ja.net (146.97.33.2)  16.498 ms  16.664 ms  30.238 ms
10  ae21.read-rbr3.ja.net (146.97.37.206)  25.150 ms  23.569 ms  24.906 ms
11  xe-2-0-0.read-rbr2.ja.net (193.63.108.129)  25.630 ms  25.531 ms  25.356 ms
12  ae2-0.oxfo-rbr2.ja.net (193.63.108.134)  29.048 ms  29.369 ms  25.778 ms
13  Oxford-University-1.ja.net (193.63.109.110)  20.092 ms  18.935 ms  24.474 ms
14  cmusb.backbone.ox.ac.uk (192.76.21.31)  22.096 ms  19.871 ms  21.351 ms
15  * * *
16  * * *
17  * * *
18  * * *
19  * * *
20  * * *
21  * * *
22  * * *
23  * * *
24  * * *
25  * * *
26  * * *
27  * * *
28  * * *
29  * * *
30  * * *

I would have expected this (what happens when 'Use only for resource on this connection' checkbox is not ticked):

Code: Select all

traceroute to micron3.bioch.ox.ac.uk (129.67.72.33), 30 hops max, 60 byte packets
 1  * * *
 2  micron3.bioch.ox.ac.uk (129.67.72.33)  20.288 ms  21.388 ms  21.860 ms

I don't know much about networking really so I'm having trouble diagnosing it from here. Perhaps the routing table that I am picking up when connecting to the VPN is lacking?

Any help would be appreciated.



On a side note, I noticed that if I try and add routes manually in this version of the network manager, they appear to be added ok, but if I go back into the 'Edit IPv4 Routes' dialogue, they are gone and never appear in the routing table.

The lack of routes being saved in the settings is probably a bug - which you might want to report at bugs.kde.org.

In terms of this issue - can you provide the output of the following command with the VPN connected?

Code: Select all

ip addr
ip route

Sorry for delay in replying. I certainly intend to report the bug.

As for the routing stuff:

With the VPN enabled and 'Use only for resources on this connection' unticked:

Code: Select all

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 10:bf:48:80:49:52 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.4/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::12bf:48ff:fe80:4952/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 94:db:c9:b4:cf:ab brd ff:ff:ff:ff:ff:ff
5: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp
    inet 129.67.76.175 peer 129.67.76.128/32 brd 129.67.76.175 scope global ppp0
       valid_lft forever preferred_lft forever


Code: Select all

$ ip route
default dev ppp0  proto static
129.67.72.248 via 192.168.0.1 dev eth0  proto static
129.67.72.248 via 192.168.0.1 dev eth0  src 192.168.0.4
129.67.76.128 dev ppp0  proto kernel  scope link  src 129.67.76.175
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.4  metric 1

With the VPN enabled and 'Use only for resources on this connection' ticked:

Code: Select all

$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
    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: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 10:bf:48:80:49:52 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.4/24 brd 192.168.0.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::12bf:48ff:fe80:4952/64 scope link
       valid_lft forever preferred_lft forever
3: wlan0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN qlen 1000
    link/ether 94:db:c9:b4:cf:ab brd ff:ff:ff:ff:ff:ff
6: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc pfifo_fast state UNKNOWN qlen 3
    link/ppp
    inet 129.67.76.140 peer 129.67.76.128/32 brd 129.67.76.140 scope global ppp0
       valid_lft forever preferred_lft forever

Code: Select all

$ ip route
default via 192.168.0.1 dev eth0  proto static
129.67.72.248 via 192.168.0.1 dev eth0  proto static
129.67.72.248 via 192.168.0.1 dev eth0  src 192.168.0.4
129.67.76.128 dev ppp0  proto kernel  scope link  src 129.67.76.140
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.4  metric 1

Thanks!

Okay - it seems this behaviour is expected to a certain extent, as the network you are connecting to is being managed in a point to point fashion - so as far as NetworkManager is concerned there is only one system on the other end of the VPN - 129.67.76.128/32 - rather than the actual network block.

Unfortunately the only easy workaround to this is using the routes field - which you previously found did not work. If you save the settings after adding each route in turn - and save it with the routes tab open, does this have any effect? (When I tried to test I could not reproduce)

Ok, that makes sense, I was sort of expecting to see some route distinguishing what is on the work network and what isn't.

Weirdly, this functionality works perfectly on OSX though, so the routes must be there in the configuration of the VPN, but for some reason not distribute to Linux.

Will look a little different as I'm in Boston, MA at the moment :

Code: Select all

douglas@starbuck:~$ netstat -nr
Routing tables

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            10.0.1.1           UGSc           10        0     en1
default            129.67.76.128      UGScI           0        0    ppp0
10.0.1/24          link#5             UCS             3        0     en1
10.0.1.1           0:1f:f3:41:2c:ff   UHLWI          11       73     en1   1167
10.0.1.22          127.0.0.1          UHS             0       50     lo0
10.0.1.255         ff:ff:ff:ff:ff:ff  UHLWbI          0        9     en1
127                127.0.0.1          UCS             0        0     lo0
127.0.0.1          127.0.0.1          UH              2      561     lo0
129.67             ppp0               USc             2        0    ppp0
129.67.72.248      10.0.1.1           UGHS           43       43     en1
129.67.76.128      129.67.76.160      UH              1        0    ppp0
169.254            link#5             UCS             0        0     en1

If there is a chance the VPN is misconfigured for Linux I will take this up with the guys at work to get it fixed. If you know, is that likely? I would guess that platform specific configs would be something offered by most VPN systems?

Finally, for when I get home to my Linux box, I assume I'm just adding the equivalent of these three?

Code: Select all

129.67             ppp0               USc             2        0    ppp0
129.67.72.248      10.0.1.1           UGHS           43       43     en1
129.67.76.128      129.67.76.160      UH              1        0    ppp0

Thanks a lot for your help so far.

Based on OS X behaving correctly, it could be that NetworkManager is not reading the metadata the VPN is sending correctly - or it is otherwise misconfiguring the connection based on the details it is sending.

I would suggest filing a bug report with the NetworkManager developers, who can likely point you in the right direction as to debugging your specific VPN issues.