OpenVPN TAP bridge - client has no internet

Installing and Using OpenWrt
1

Wondering if someone can help. I have posted a similar post to OpenVPN forums but no reply.

I have set up an OpenVPN TAP server on OWRT router #1 on 192.168.2.x subnet. I have a bridged client TAP setup on OWRT router #2.

When connected to LAN2 (tap bridge) on router 2 (client) I can access the server, ping devices on it, see devices on IP Scanner app. I receive an IP address from the server as expected. I can access router 1 Luci and router 2 luci (192.168.2.1 and 192.168.2.2, respectively). I cannot access the internet from the client side.

Client side I can ping 8.8.8.8 or google.com and it receives a response. Using nslookup I get the following:

% nslookup google.com 192.168.2.1

Server: 192.168.2.1

Address: 192.168.2.1#53

Non-authoritative answer:

Name: google.com

Address: 142.250.189.14

Traceroute also shows traffic going through the VPN and shows a connection to the outside world from the client. If I open Chrome or Safari and try to browse no webpage will load. I have narrowed this down to perhaps being a DNS issue. Any thoughts? My logs don't show anything unusual that might narrow down this problem (set to verb 5). I have seen a few posts stating to add option localservice '0' to /etc/config/dhcp but am unsure if this would be on the client or server side and I don't want to risk making either router inoperable without further advice.

Thanks!

2

I have not configured tap on OpenWRT, so it is only my guess.

Please, give configuration files omitting private information for server, and client. Have you configured compression?

3

Some long shots:

If you have installed DNS hijacking remove that on the client side
Disable Rebind Protection on the client side

Maybe your browsers are using DoT or DoH which is blocked on the server side?

I also never used OpenVPN TAP on OpenWRT (I would instead use WireGuard and some layer 2 tunnelling e.g. GRETAP)

4

I have setup WireGuard on the server router as an alternate connection. I will look into GRETAP. I am not aware of DNS hijacking being installed, but can check next time I get on. Where might I find Rebind Protection if it’s enabled? Is it under the Interface settings? Firewall?

I do not have access to my computer at the moment but will post my configs when I get back home later.

@ulmwind - compression is not enabled currently.

5

Why tap and not tun? Generally speaking, tap is not recommended because all the l2 broadcast traffic will be sent though the tunnel, which is inefficient t and can slow the network down. If there are specific l2 needs that cannot be handled in any other way, that is the only real reason for a tap interface these days.

And if you do go with tun instead, wireguard (which you said you have already configured) is much more performant.

2 Likes
6

I got this question a lot when I was first looking into TAP options.

I have one device client side that's ethernet only that needs to be on the same subnet as an IoT device that's server side. Multicast is required. The bridged TAP interface is purely for this one device. The wireguard interface is also directed to the server router and I will be using that for everything else. The client side device also has the ability to stream, so it needs to be able to reach the internet through the tunnel.

I was not aware of GRETAP, or other TAP alternatives that can utilize a protocol like WireGuard. For now I'd like to see if I can finish getting OpenVPN working as expected and then I can look into alternatives.

7

Uploading the config files if this helps!

Server Config

config openvpn 'Tap_Server'
        list push 'dhcp-option DNS 192.168.2.1'
#       list push 'dhcp-option DNS 8.8.8.8'
        option data_ciphers 'CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM'
        option auth 'SHA256'
        option tls_ciphersuites 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384'
        option tls_version_min '1.3'
        option client_to_client '1'
        option dev 'tap'
        option keepalive '10 120'
        option tun_mtu '1500'
        option proto 'udp'
        option persist_key '1'
        option persist_tun '1'
        option port '7000'
        option remote_cert_tls 'client'
        option server_bridge '192.168.50.1 255.255.255.0 192.168.50.35 192.168.50.45'
        option verb '5'
        option ifconfig_pool_persist '/tmp/ipp.txt'
        option enabled '1'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/Server_SiteA.crt'
        option key '/etc/openvpn/Server_SiteA.key'
        option dh '/etc/openvpn/dh.pem'

Client Config

config openvpn 'VPN_Tap_Client'
        option auth_nocache '1'
        option enabled '1'
        option data_ciphers 'CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM'
        option auth 'SHA256'
        option tls_version_min '1.3'
        option client '1'
        option tls_client '1'
        option resolv_retry 'infinite'
        option dev 'tap'
        option float '1'
        option nobind '1'
        option proto 'udp'
        option port '7000'
        option tun_mtu '1500'
        option persist_key '1'
        option persist_tun '1'
        option remote_cert_tls 'server'
        option key_direction '1'
        option verb '5'
        option reneg_sec '0'
        option ca '/etc/openvpn/ca.crt'
        option cert '/etc/openvpn/Client_SiteB_SiteA.crt'
        option key '/etc/openvpn/Client_SiteB_SiteA.key'
        list tls_ciphersuites 'TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384'
        list remote 'xxxxxxxxxxxxxxxx'
8

Rebind Protection is under Network > DHCP and DNS > General Settings
Will probably not solve your problem but who knows

afbeelding
afbeelding1289×78 4.81 KB

9

First of all, I like to use 'native' config files, and make link to them in OpenWRT-configuration.

OK, and what about route command on client, and using commented option 8.8.8.8?

10

Since you have OpenWrt on both ends it is probably best to not use any OpenVPN network management features, and treat the tap bridge as a virtual Ethernet cable, basically like a remote dumb AP. This means configure a server-bridge directive with no parameters. The only DHCP server should be the one in the router on the server side. The client side router must not run DHCP on its lan / bridged interface so it will not serve up conflicting settings.

11

I appreciate all the suggestions! I'm away for Thanksgiving but will give this a go when I get back!

First of all, I like to use 'native' config files, and make link to them in OpenWRT-configuration. OK, and what about route command on client, and using commented option 8.8.8.8?

@ulmwind - can you tell me what you mean by 'native' config files? Are you suggesting to replace push dhcp-option DNS 192.168.2.1 with push route 192.168.2.1 255.255.255.0 - remove push dhcp from server and apply push route in client?

I tried using push dhcp-option DNS 8.8.8.8 and it appeared to break my config, but I may have missed something else.

I think you're referencing what @ulmwind is saying above. Can you give me an example? I have it set up currently as a TAP Bridge and it works, just without access to the internet from a browser, despite being able to ping from the client. Should I remove the push DHCP such as above from the server config? I think you guys might be right. This could be causing DNS resolve issues.

For reference, I followed this tutorial with the updated instructions in the comments for OpenWRT 21 and above.

12

Just to create 'native' OpenVPN-config file, and make link to it in OpenWRT-config:
see section 'sample-client' in default /etc/config/openvpn. You can also make '.conf' extension, in this case openvpn-daemon loads file automatically.

1 Like
13

I'll have to look into this. When I initially set this up I did clear the /etc/config/openvpn file with > openvpn - so I don't have that anymore and it's been replaced with my current config, unless someone can be kind enough to post it.

You're saying if this was configured as TAP this would push the server over the tunnel and not require further config? For example, dhcp-option, route, etc wouldn't be required?

14 
config openvpn myserver
   option config '/etc/openvpn/server.ovpn'
   option enabled '1'

I don't recommend naming a native config file .conf as that will interfere with the UCI service startup above.

If you run TAP and bridge it into the LAN on both sides, clients on the remote side making a DHCP request will be passed through the tunnel and the request will be answered by the regular OpenWrt DHCP server on the server side. In other words, OpenVPN isn't involved in DHCP at all, it works like an Ethernet cable.

TAP bridge should be restricted to small networks, as it is easy for the tunnel bandwidth to get filled up with broadcast traffic. Most deployments should use TUN unless there's a really good reason not to.

1 Like
15

Thank you, @mk24.

Regardless of .conf or .opvn file usage, is there any documentation you can point me towards to achieve this sort of setup?

With regards to my current config (server on 192.168.2.1 and client on 10.0.1.x) I'm assuming that client side I will still bridge the tap0 interface with eth2 (in my case) and create a new relevant interface with a static IP of 192.168.2.2.

Server side, I would add

config openvpn myserver
   option config '/etc/openvpn/server.ovpn'
   option enabled '1'

to /etc/config/openvpn.

Inside of server.ovpn I'm assuming something like the following...?

dev tap
proto udp
port 7000

ca ...crt
cert ...crt
key ...key
dh ...pem

server-bridge 192.168.2.1 255.255.255.0 192.168.2.100 192.168.2.150
push "dhcp-option DNS 192.168.2.1"
push "dhcp-option DOMAIN yourdomain.local"

keepalive 10 120
comp-lzo
user nobody
group nogroup

persist-key
persist-tun

However, you're saying OpenVPN would not handle DHCP at all, so perhaps I'm confused.

16

tap is just bridge, so I suppose, you do not need to add routing options. Maybe to configure up-down events.

17

Ah ok cool. I’m guessing more in this realm then? I’ll have to research up/down events as I’ve never used them before.

mode server
dev tap
ca ...crt
cert ...crt
key ...key
server-bridge 192.168.2.1 255.255.255.0 192.168.2.100 192.168.2.200
push "route-gateway 192.168.2.1"
push "redirect-gateway def1 bypass-dhcp"
client-to-client

I am deploying the server router at a distant location to test for a few days tomorrow. I have a wireguard interface setup, so I should be able to maintain access to the server in the event mess up the OVPN tap tunnel.

18

Use server-bridge with no further options on the line. This will prevent OpenVPN from acting as a DHCP server, which is what you want since there is already a DHCP server on the LAN.
Similarly, pushing DHCP options becomes moot in that case. Remove those.

19

I've disabled my previous OVPN server and had enabled this:

mode server

dev tap
proto udp
port 7000

ca ...crt
cert ...crt
key ...key
dh ...pem

data-ciphers CHACHA20-POLY1305:AES-256-GCM:AES-128-GCM
auth SHA256
tls-ciphersuites TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384
tls-version-min 1.3
remote-cert-tls client
keepalive 10 120

server-bridge 192.168.2.1 255.255.255.0 192.168.2.110 192.168.2.120
client-to-client
verb 5

I'm assuming the TAP interface on the client is now moot as well? Under devices, I have bridged tap0 to the LAN on server side and I have bridged tap0 and eth2 on client side (tap_lan). Will test this tomorrow.

I'm assuming no modifications need to be made to the /etc/config/dhcp file.

Question - on the server-bridge line are you suggesting to just have server-bridge with no subnet mask and no ip addresses? So...

server-bridge
client-to-client
verb 5

Client side, the previously configured TAP interface I had created from the original tutorial was what I set up the firewall with. I'm assuming a new firewall config will need to be created.

I appreciate your help!

20

The OpenVPN TAP interface on the client needs to be added to br-lan. The DHCP server on the client LAN needs to be disabled. You may want to create an "admin" interface with a different IP subnet and a DHCP server so that you can connect and login to the client while the VPN is down.

The situation is almost exactly like connecting a dumb AP to a main router with an Ethernet cable, only now the cable is virtual. As in that case the firewall isn't an issue in lan-lan communication since that occurs at layer 2. Of course the wan networks and firewall need to be set up so that the outer tunnel connection is made.