Topic: OpenVPN (TAP) - Can't reach any IP

The content of this topic has been archived on 25 Mar 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.

Page 1 of 1

Post #1

markdark81

19 Jul 2017, 09:41

I have followed the guide "OpenVPN Setup Guide for Beginners" from the OpenWRT Wiki (can not post links) and created a TAP setup.

The router has an internal network of 172.22.22.0/24.
My vpn-client connects from an internal network of 192.168.178.0/24.
The VPN client is installed on Ubuntu 16.04 LTS laptop. When I start my VPN it connects perfectly, see:

● openvpn@home-vpn.service - OpenVPN connection to home-vpn
   Loaded: loaded (/lib/systemd/system/openvpn@.service; disabled; vendor preset: enabled)
   Active: active (running) since wo 2017-07-19 08:17:18 CEST; 1h 34min ago
     Docs: man:openvpn(8)
           <doc link 1>
           <doc link 2>
  Process: 957 ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status /run/openvpn/%i.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/%i.conf --wr
 Main PID: 1008 (openvpn)
   CGroup: /system.slice/system-openvpn.slice/openvpn@home-vpn.service
           └─1008 /usr/sbin/openvpn --daemon ovpn-home-vpn --status /run/openvpn/home-vpn.status 10 --cd /etc/openvpn --script-security 2 --config /etc/openvpn/home-vp

jul 19 08:17:18 my-laptop systemd[1]: Starting OpenVPN connection to home-vpn...
jul 19 08:17:18 my-laptop systemd[1]: Started OpenVPN connection to home-vpn.

Also the openvpn.log file shows no issues:

Wed Jul 19 09:17:30 2017 TLS: soft reset sec=0 bytes=53803/0 pkts=812/0
Wed Jul 19 09:17:31 2017 VERIFY OK: depth=1, C=NL, ST=State, L=Place, O=n/a, OU=home, CN=<dns>, name=EasyRSA, emailAddress=myself@gmail.com
Wed Jul 19 09:17:31 2017 Validating certificate key usage
Wed Jul 19 09:17:31 2017 ++ Certificate has key usage  00a0, expects 00a0
Wed Jul 19 09:17:31 2017 VERIFY KU OK
Wed Jul 19 09:17:31 2017 Validating certificate extended key usage
Wed Jul 19 09:17:31 2017 ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Wed Jul 19 09:17:31 2017 VERIFY EKU OK
Wed Jul 19 09:17:31 2017 VERIFY OK: depth=0, C=NL, ST=State, L=Place, O=n/a, OU=home, CN=<dns>, name=EasyRSA, emailAddress=myself@gmail.com
Wed Jul 19 09:17:32 2017 Data Channel Encrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jul 19 09:17:32 2017 WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
Wed Jul 19 09:17:32 2017 Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 19 09:17:32 2017 Data Channel Decrypt: Cipher 'BF-CBC' initialized with 128 bit key
Wed Jul 19 09:17:32 2017 WARNING: this cipher's block size is less than 128 bit (64 bit).  Consider using a --cipher with a larger block size.
Wed Jul 19 09:17:32 2017 Data Channel Decrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Wed Jul 19 09:17:32 2017 Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA

But when I try to ping the router/openvpn server ip address 172.22.22.1, I get no answer at all.
When I temporarily disable the firewall on the OpenWRT, it does not help either.
So it seems that no traffic is routed through the tunnel. I also see no extra interface on my Ubuntu laptop.

This is the ifconfig output on my laptop running the VPN client and being connected:

enp6s0    Link encap:Ethernet  HWaddr 40:16:7e:94:27:e0  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:13045 errors:0 dropped:0 overruns:0 frame:0
          TX packets:13045 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1 
          RX bytes:2256731 (2.2 MB)  TX bytes:2256731 (2.2 MB)

wlp5s0    Link encap:Ethernet  HWaddr ac:7b:a1:a4:3c:1f  
          inet addr:192.168.178.40  Bcast:192.168.178.255  Mask:255.255.255.0
          inet6 addr: fe80::b19:6201:5391:71e9/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:249473 errors:0 dropped:0 overruns:0 frame:0
          TX packets:38910 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:348096384 (348.0 MB)  TX bytes:6405360 (6.4 MB)

I do not see any extra interface on my laptop, would that be the issue?

/etc/config/network:

config interface 'loopback'
    option ifname 'lo'
    option proto 'static'
    option ipaddr '127.0.0.1'
    option netmask '255.0.0.0'

config globals 'globals'
    option ula_prefix 'fdd3:7c20:d49d::/48'

config interface 'lan'
    option type 'bridge'
    option proto 'static'
    option ipaddr '172.22.22.1'
    option netmask '255.255.255.0'
    option ip6assign '60'
    option ifname 'eth0.1 tap0'

config interface 'wan'
    option ifname 'eth0.2'
    option proto 'dhcp'

config interface 'wan6'
    option ifname 'eth0.2'
    option proto 'dhcpv6'

config switch
    option name 'switch0'
    option reset '1'
    option enable_vlan '1'

config switch_vlan
    option device 'switch0'
    option vlan '1'
    option ports '1 2 3 4 8t'

config switch_vlan
    option device 'switch0'
    option vlan '2'
    option ports '0 8t'

config interface 'vpn0'
    option ifname 'tap0'
    option proto 'none'
    option auto '1'

/etc/config/firewall

config defaults
    option syn_flood '1'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'REJECT'

config zone
    option name 'lan'
    list network 'lan'
    option input 'ACCEPT'
    option output 'ACCEPT'
    option forward 'ACCEPT'

config zone
    option name 'wan'
    list network 'wan'
    list network 'wan6'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'
    option mtu_fix '1'

config forwarding
    option src 'lan'
    option dest 'wan'

config rule
    option name 'Allow-DHCP-Renew'
    option src 'wan'
    option proto 'udp'
    option dest_port '68'
    option target 'ACCEPT'
    option family 'ipv4'

config rule
    option name 'Allow-Ping'
    option src 'wan'
    option proto 'icmp'
    option icmp_type 'echo-request'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-IGMP'
    option src 'wan'
    option proto 'igmp'
    option family 'ipv4'
    option target 'ACCEPT'

config rule
    option name 'Allow-DHCPv6'
    option src 'wan'
    option proto 'udp'
    option src_ip 'fc00::/6'
    option dest_ip 'fc00::/6'
    option dest_port '546'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-MLD'
    option src 'wan'
    option proto 'icmp'
    option src_ip 'fe80::/10'
    list icmp_type '130/0'
    list icmp_type '131/0'
    list icmp_type '132/0'
    list icmp_type '143/0'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Input'
    option src 'wan'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    list icmp_type 'router-solicitation'
    list icmp_type 'neighbour-solicitation'
    list icmp_type 'router-advertisement'
    list icmp_type 'neighbour-advertisement'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config rule
    option name 'Allow-ICMPv6-Forward'
    option src 'wan'
    option dest '*'
    option proto 'icmp'
    list icmp_type 'echo-request'
    list icmp_type 'echo-reply'
    list icmp_type 'destination-unreachable'
    list icmp_type 'packet-too-big'
    list icmp_type 'time-exceeded'
    list icmp_type 'bad-header'
    list icmp_type 'unknown-header-type'
    option limit '1000/sec'
    option family 'ipv6'
    option target 'ACCEPT'

config include
    option path '/etc/firewall.user'

config rule
    option src 'wan'
    option dest 'lan'
    option proto 'esp'
    option target 'ACCEPT'

config rule
    option src 'wan'
    option dest 'lan'
    option dest_port '500'
    option proto 'udp'
    option target 'ACCEPT'

config rule 'Allow_OpenVPN_Inbound'
    option target 'ACCEPT'
    option src '*'
    option proto 'udp'
    option dest_port '1194'

/etc/config/openvpn:

config openvpn 'myvpn'
    option enabled '1'
    option verb '3'
    option proto 'udp'
    option port '1194'
    option dev 'tap'
    option mode 'server'
    option tls_server '1'
    list push 'route-gateway dhcp'
    list push 'redirect-gateway def1'
    option keepalive '10 120'
    option ca '/etc/openvpn/ca.crt'
    option cert '/etc/openvpn/my-server.crt'
    option key '/etc/openvpn/my-server.key'
    option dh '/etc/openvpn/dh2048.pem'

home-vpn.ovpn (vpn client config):

dev tap
proto udp

log openvpn.log
verb 3

ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key

client
remote-cert-tls server
remote <dns> 1194

Post #2

Antek

19 Jul 2017, 10:20

You have defined a network 'vpn0' that is associated with the 'tap0' virtual interface created by your OpenVPN server on the router. You have also bridged 'tap0' with the 'eth0.2' in the 'lan' network. I think you should remove the 'vpn0' network, as it seems to be unnecessary?

Also, on the client side, use 'ifconfig -a' to see all network interfaces, instead of just the active ones. Perhaps the client-side 'tap' interface is simply not active for some reason?

There's a subtle but distinct difference between the low-level connection (OpenVPN server <-> OpenVPN client), and the virtual interface that represents the secure communication channel that becomes available once the server and the client have successfully negotiated the underlying link. You will need to configure this virtual interface on the client to use DHCP protocol and then bring it up.

Hope this helps

Post #3

markdark81

19 Jul 2017, 10:54

Antek wrote:

You have defined a network 'vpn0' that is associated with the 'tap0' virtual interface created by your OpenVPN server on the router. You have also bridged 'tap0' with the 'eth0.2' in the 'lan' network. I think you should remove the 'vpn0' network, as it seems to be unnecessary?

Well in the beginners guide on the OpenWRT Wiki it states below "Configure the network on the OpenWRT router":

uci set network.vpn0=interface
uci set network.vpn0.ifname=tap0
uci set network.vpn0.proto=none
uci set network.vpn0.auto=1

And also:

uci set network.lan.ifname="$(uci get network.lan.ifname) tap0"

This can be found below the TAP setup. Which will do what is desribed.

Antek wrote:

Also, on the client side, use 'ifconfig -a' to see all network interfaces, instead of just the active ones. Perhaps the client-side 'tap' interface is simply not active for some reason?

I have to look at this later today. I tried to change some `/etc/config/network` settings and restarted with `/etc/init.d/network restart`, but now I can't reach my home network anymore. Think something got stuck at home. Will see later on.

Antek wrote:

There's a subtle but distinct difference between the low-level connection (OpenVPN server <-> OpenVPN client), and the virtual interface that represents the secure communication channel that becomes available once the server and the client have successfully negotiated the underlying link. You will need to configure this virtual interface on the client to use DHCP protocol and then bring it up.

Not sure what to do here. I thought that the VPN client would create a interface?

Post #4

Antek

19 Jul 2017, 19:58

markdark81 wrote:

Well in the beginners guide on the OpenWRT Wiki it states below "Configure the network on the OpenWRT router":
uci set network.vpn0=interface
uci set network.vpn0.ifname=tap0
uci set network.vpn0.proto=none
uci set network.vpn0.auto=1
And also:
uci set network.lan.ifname="$(uci get network.lan.ifname) tap0"
This can be found below the TAP setup. Which will do what is desribed.

I'd surmise that the author of the guide was after the 'auto' option for the 'tap0' virtual interface, in order to bring it up automatically on boot. I do not know if bringing an interface up is necessary in order to join it to a bridge, or if the bridge can bring up the interfaces associated with it automatically.

But since it is there, might as well leave this configuration snippet alone. I haven't read the beginner's guide, so I didn't know about this. Sorry about the confusion

markdark81 wrote:

Not sure what to do here. I thought that the VPN client would create a interface?

The client is responsible for creating the interface. However, since this is a bridged setup on the server-end, the server just "plugs" its own virtual interface into whatever network you tell it to (in this case, the 'lan' network) and then forgets about it.

After the server and the client have negotiated the link, the client is now sitting there with an interface that is ready to go, but does not have any settings. What you need to do is tell it how to proceed. Most likely what you want to do is use a DHCP client to receive an IP address from the DHCP server that is sitting at the bridge junction (the 'lan' network) on the server end, and configure the interface using the received settings.

I haven't used Ubuntu's desktop versions much, so if you have a desktop environment installed and you want to configure the interface automatically upon boot, then you'll need to check it's manual in order to configure the network interface.

If you want to try the command-line way, then I think Ubuntu supports a similar command-set as my Debian installation, so first check 'ifconfig -a' on your client computer and see if the interface is created successfully. You should see the interface that your OpenVPN client created. It is most likely called 'tap0'. Ensure that the interface is 'down' i.e. 'ifconfig -a' does not show either "UP" or "RUNNING" states for the interface.

You can now call 'dhclient tap0' (or whatever the interface name is) in order to configure a DHCP client to control this interface. Then call 'ifconfig tap0 up' to make it operational. After this, issuing 'ifconfig' should now show the interface as UP and RUNNING, and it should've received an IP address from the 172.22.22.0/24 address range (or whatever range you've configured for the DHCP server on your router).

Post #5

markdark81

20 Jul 2017, 17:53

Thank you very much Antek. It wasn't clear to me I still had to bring the tap0 interface up on the VPN client side. When I do this manually like you say it works like a charm.
I find it a bit strange this is needed manually, because on most Ubuntu sites and explanations about TAP en OpenVPN say that bringing up the VPN is enough. So I will dive more into this (self or with Ubuntu community).
But thanks for pointing this out.

For now I added a simple BASH script (without a lot of failure checks) to fire up my VPN, if people are interested:

#!/bin/bash

USAGE="Usage: homevpn start/stop/status"

case ${1} in
  "start")
    echo "Firing up VPN. please wait"
    sudo systemctl start openvpn@home-vpn

    echo "VPN connected, waiting for tap0 interface"
    until ifconfig tap0 > /dev/null 2>&1
    do
        sleep 1
    done

    echo "tap0 interface found, getting DHCP address"
    sudo ifconfig tap0 down && sudo dhclient tap0 && sudo ifconfig tap0 up

    echo "Got IP address, ready to go!"
  ;;
  "stop")
    sudo systemctl stop openvpn@home-vpn
  ;;
  "status")
    sudo systemctl status openvpn@home-vpn
  ;;
  *)
    echo "${USAGE}"
    exit 1
  ;;
esac

The discussion might have continued from here.

Page 1 of 1