Making an openvpn client reachable from lan

duquesnc · 2012-06-04 07:07:16

Hi,

I suscribed to an openvpn provider. I configured a machine of my network to run as a client for this vpn. I shall call this machine A.

Once I start the openvpn daemon on A, I cannot ping it from my lan anymore. While I am happy that the default route has been set to be through the vpn, I would really like to still be able to ping A from my lan, since I also stream sound from the lan to this machine using pulseaudio.

I added commands to be run after openvpn has started:

ip rule add from 192.168.0.0/24 table 10
ip rule add to 192.168.0.0/24 table 10
ip route add default via 192.168.0.1 dev eth0 table 10

When I monitor pings using tcpdump on A, I see that A tries to respond to ping, but I don't see the actual answer on the other end.

 % sudo tcpdump -i eth0 icmp     
Password: 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
08:54:43.150428 IP 192.168.0.10 > 192.168.0.13: ICMP echo request, id 6379, seq 1, length 64
08:54:43.150461 IP 192.168.0.13 > 192.168.0.10: ICMP echo reply, id 6379, seq 1, length 64
08:54:44.149572 IP 192.168.0.10 > 192.168.0.13: ICMP echo request, id 6379, seq 2, length 64
08:54:44.149616 IP 192.168.0.13 > 192.168.0.10: ICMP echo reply, id 6379, seq 2, length 64
08:54:45.150587 IP 192.168.0.10 > 192.168.0.13: ICMP echo request, id 6379, seq 3, length 64
08:54:45.150618 IP 192.168.0.13 > 192.168.0.10: ICMP echo reply, id 6379, seq 3, length 64

While on the machine trying to ping A:

 % ping A
PING A(192.168.0.13) 56(84) bytes of data.
^C
--- A ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 1999ms

Here are various commands run on A after the vpn has started (and after I have run my ip commands).

% ip route show
0.0.0.0/1 via 10.0.15.210 dev tun0 
default via 192.168.0.1 dev eth0  metric 202 
10.0.8.1 via 10.0.15.210 dev tun0 
10.0.15.210 dev tun0  proto kernel  scope link  src 10.0.15.209 
128.0.0.0/1 via 10.0.15.210 dev tun0 
178.209.50.214 via 192.168.0.1 dev eth0 
192.168.0.0/24 dev eth0  proto kernel  scope link  src 192.168.0.13  metric 202 

% ip rule list 
0:      from all lookup local 
32764:  from all to 192.168.0.0/24 lookup 10 
32765:  from 192.168.0.0/24 lookup 10 
32766:  from all lookup main 
32767:  from all lookup default 

% ifconfig 
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500  metric 1
        inet 192.168.0.13  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::225:22ff:feb4:d99e  prefixlen 64  scopeid 0x20<link>
        ether 00:25:22:b4:d9:9e  txqueuelen 1000  (Ethernet)
        RX packets 738861  bytes 382781851 (365.0 MiB)
        RX errors 0  dropped 72  overruns 0  frame 0
        TX packets 494977  bytes 46998884 (44.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 41  base 0x8000  

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 16436  metric 1
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 0  (Local Loopback)
        RX packets 186755  bytes 15966304 (15.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 186755  bytes 15966304 (15.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500  metric 1
        inet 10.0.15.209  netmask 255.255.255.255  destination 10.0.15.210
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 14  bytes 2072 (2.0 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 21  bytes 1983 (1.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Oh, and my lan is very classically configured as 192.168.0.0/24, with the router being 192.168.0.1. On the machine I pinged A from:

% ip route show     
default via 192.168.0.1 dev wlan0  metric 303 
192.168.0.0/24 dev wlan0  proto kernel  scope link  src 192.168.0.10  metric 303

% ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 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
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000
    link/ether d4:be:d9:11:7c:e5 brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
    link/ether 88:53:2e:83:13:28 brd ff:ff:ff:ff:ff:ff
    inet 192.168.0.10/24 brd 192.168.0.255 scope global wlan0
    inet6 fe80::8a53:2eff:fe83:1328/64 scope link 
       valid_lft forever preferred_lft forever

I'd be happy to provide more informations if requested.

Last edited by duquesnc (2012-06-04 08:00:02)

Gcool · 2012-06-04 07:46:46

Your general routing,... looks fine. But just out of curiousity, why are you making changes to the routing db (ip rule)?

duquesnc · 2012-06-04 07:56:04

Well, I have been reading this post on the openvpn forum and I thought my problem was similar: the remote openvpn server pushes a default route, and I thought defining a second routing table would allow me to circumvent this route for hosts of my lan.

There is probably something I don't get, but I don't know what...

Gcool · 2012-06-04 08:12:50

Ok, I see.

In your specific case, this isn't needed. Once the vpn tunnel is set up, a default route will indeed be pushed, effectively routing all traffic through the tunnel. However, if you want to make exceptions to that (like your local lan for example), simply add those exceptions to the existing route table. There's no need to involve multiple route tables (for home usage, there's almost never a reason to do this).

So simply undo those ip rule changes you made and add "ip route add 192.168.0.0/24 dev eth0" to your main routing table if this route isn't preserved (added automatically) after the tunnel is set up.

Last edited by Gcool (2012-06-04 08:31:03)

duquesnc · 2012-06-04 08:25:24

Ok, but I am not sure to fully understand the effect of this command.

I still want A to use tun0 as a default interface. For example, if I start a browser on A, I want to be sure all the connections will go through the vpn.

If I do that, won't all the traffic on A go through eth0 as a default rule, thus defeating the vpn?

Gcool · 2012-06-04 08:32:56

Luckily you read comprehensively

You're right, I copy/pasted the wrong route. You'd want to add a route for the 192.168.0.0/24 subnet, not change the default route obviously. I've corrected my previous post to show the correct command.

duquesnc · 2012-06-04 08:36:14

Thank you very much

I lost my remote access to the machine in question while messing with ip commands, but I will try that when I'll be back home

duquesnc · 2012-06-05 07:28:01

Yay thank you, it works!

But my problem is not fully resolved yet: I also do port forwarding in my box, and I serve ssh and http servers with a dynamic dns. I thought allowing traffic from 192.168.0.0/24 would have allowed anything from the router (192.168.0.1) and thus make my servers available, but apparently that is not the case...

How can i allow A to go on serving on my router's public ip?

Last edited by duquesnc (2012-06-05 07:28:26)

Gcool · 2012-06-05 08:18:44

That's a bit of a tricky issue indeed. The traffic destined for your server will most likely be hitting your Archbox correctly, but the reply traffic will be routed through the vpn tunnel and hence "get lost".

This is probably solvable by tinkering with routing based on source port or so. But for an easy, transparent solution; is it perhaps an option to simply have your dns name refer to your vpn's public ip and have the server accessed that way?

duquesnc · 2012-06-05 08:28:32

Hum, I see. But the solution you propose does not fit the type of vpn I use: they don't allow port-forwarding, so the requests will probably blocked at the other end of the vpn.

What about the routing based on the source port? Can you do that with the 'ip' command or do you have to use something like iptables? I found a resource giving some background about it: http://www.linuxhorizon.ro/iproute2.html, I'll have a look...

Arch Linux

#1 2012-06-04 07:07:16

Making an openvpn client reachable from lan

#2 2012-06-04 07:46:46

Re: Making an openvpn client reachable from lan

#3 2012-06-04 07:56:04

Re: Making an openvpn client reachable from lan

#4 2012-06-04 08:12:50

Re: Making an openvpn client reachable from lan

#5 2012-06-04 08:25:24

Re: Making an openvpn client reachable from lan

#6 2012-06-04 08:32:56

Re: Making an openvpn client reachable from lan

#7 2012-06-04 08:36:14

Re: Making an openvpn client reachable from lan

#8 2012-06-05 07:28:01

Re: Making an openvpn client reachable from lan

#9 2012-06-05 08:18:44

Re: Making an openvpn client reachable from lan

#10 2012-06-05 08:28:32

Re: Making an openvpn client reachable from lan

Board footer