Issues with OpenVPN TAP setup

[sc250024]

Greetings,

First time posting, but I've used the Merlin firmware since 2016. Love it! Anyway, I'm wanting to set up a simple layer 2 (TAP) based VPN using OpenVPN. I currently have a working layer 3 (TUN) OpenVPN setup, but I want to extend it to have a layer 2 option on "Server 2." I used the GUI, and performed the most basic setup whereby the router generated the keys / certificates, and with most of the default encryption settings; this is shown in the attached picture. My Internet setup is as simple as can be, where the ISP modem / router combo is in bridge mode, and is just acting as a modem. See here for a diagram (MermaidJS). At this point, I'm simply trying to get it to work before tweaking security settings.

I download the generated client configuration from the VPN UI (it is attached as client2.txt). After connecting to the Wi-Fi hotspot on my phone, I test the VPN. I can connect, but I cannot reach the Internet, nor any devices on the LAN itself.

I feel like I'm missing something obvious, but I cannot quite figure out what it is. I have attached the previously mentioned items (picture of config, and OpenVPN client config) as well as:

• Server config from the ASUS router
• The routing table after I connect to the VPN
• The Tunnelblick log.

What's interesting is that I am assigned an IP address from my home LAN on the interface (en0) but still nothing happens.

Can anyone replicate this on their ASUS? What's missing exactly?

# Before VPN
$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
64 bytes from 8.8.8.8: icmp_seq=0 ttl=117 time=51.304 ms
64 bytes from 8.8.8.8: icmp_seq=1 ttl=117 time=48.079 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=117 time=35.595 ms
64 bytes from 8.8.8.8: icmp_seq=3 ttl=117 time=31.257 ms
64 bytes from 8.8.8.8: icmp_seq=4 ttl=117 time=144.935 ms


--- 8.8.8.8 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 31.257/62.234/144.935/42.020 ms

# After VPN
$ ping -c 5 8.8.8.8
PING 8.8.8.8 (8.8.8.8): 56 data bytes
ping: sendto: No route to host
ping: sendto: No route to host
Request timeout for icmp_seq 0
ping: sendto: No route to host
Request timeout for icmp_seq 1
ping: sendto: No route to host
Request timeout for icmp_seq 2
ping: sendto: No route to host
Request timeout for icmp_seq 3


--- 8.8.8.8 ping statistics ---
5 packets transmitted, 0 packets received, 100.0% packet loss

 

[eibgrad]

Please post the output from the following commands on the mac.

ifconfig
brctl show

Note: I don't own or use a mac, but I assume being Linux based, these commands are supported.

 

[sc250024]

The utility brctl actually is on macOS, but it's completely unrelated to network bridging. See here: https://github.com/kendfinger/MacHack#brctl

What information do you need?

 

[eibgrad]

Like probably most users in this forum, I'm not familiar enough w/ macOS to know the Linux equivalents, so let me explain what I'm looking for.

In the dump of the routing table you provided, I see no sign of the OpenVPN client's network interface (tap#), but only your default/LAN network interface (en0). So I wanted to see a dump of all your network interfaces (ifconfig) and determine whether the OpenVPN client's network interface was bridged to the LAN (which the brctl command on Linux would reveal). Because when it comes to the client side of this connection, this is NOT what you want! But based on the routing table, it appears that may be what happened. You can't manage both the local and remote networks from en0.

The best way to see what I mean is to return to the routed (tun) OpenVPN client configuration and dump the routing table again. I suspect you'll now see the OpenVPN client's network interface (e.g., tun#) in the dump.

To illustrate my point further, here's a dump of my router when using a *routed* (tun) OpenVPN server configuration.

admin@merlin-lab1:/tmp/home/root# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.63.1    0.0.0.0         255.255.255.255 UH        0 0          0 vlan2
10.8.0.0        0.0.0.0         255.255.255.0   U         0 0          0 tun21
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
192.168.63.0    0.0.0.0         255.255.255.0   U         0 0          0 vlan2
192.168.61.0    192.168.63.1    255.255.255.0   UG        0 0          0 vlan2
192.168.61.0    192.168.63.1    255.255.255.0   UG        0 0          0 vlan2
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         192.168.63.1    0.0.0.0         UG        0 0          0 vlan2

Notice the VPN's network interface (tun21) appears in the routing table.

If I now change the OpenVPN config to bridged (tap), here's both the routing table and bridging table.

admin@merlin-lab1:/tmp/home/root# netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.63.1    0.0.0.0         255.255.255.255 UH        0 0          0 vlan2
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 br0
192.168.63.0    0.0.0.0         255.255.255.0   U         0 0          0 vlan2
192.168.61.0    192.168.63.1    255.255.255.0   UG        0 0          0 vlan2
192.168.61.0    192.168.63.1    255.255.255.0   UG        0 0          0 vlan2
127.0.0.0       0.0.0.0         255.0.0.0       U         0 0          0 lo
0.0.0.0         192.168.63.1    0.0.0.0         UG        0 0          0 vlan2

admin@merlin-lab1:/tmp/home/root# brctl show
bridge name     bridge id               STP enabled     interfaces
br0             8000.1cb72ccb0960       yes             vlan1
                                                        eth1
                                                        eth2
                                                        tap21

Notice the OpenVPN's network interface (tap21) is NOT in the routing table anymore since it's been bridged to the private/default local network (br0).

On the client side, you do NOT want this. You want the tap network interface to remain *un*bridged to the local network (in your case, en0) and managed separately. If it was unbridged, I would have expected the tap# network interface to have appeared in your dump of the routing table on macOS. But it doesn't appear to be there, so I can only assume that in fact it got bridged to the local network.

Again, I'm at a disadvantage here since I'm not a macOS user. But the problem you're having may be more related to macOS and how it's (mis)handling a bridged OpenVPN client than anything to do w/ the router.

 

[sc250024]

Thank you for the detailed reply! For fun, I tried installing the OpenVPN config on a Windows machine, and it worked successfully. It seems to be a problem with macOS because I also tried installing Pritunl client (https://client.pritunl.com/) and Viscosity (https://www.sparklabs.com/viscosity/) and both of them failed as well.

I think this thread should be renamed "Getting TAP-based OpenVPN to work on macOS."

I attached the results of ifconfig while connected to the VPN. The bridge0 is actually Thunderbolt in this case.