Gateway gets stripped from DHCP Reply through OpenVPN tunnel

Question

I have a bridged OpenVPN setup. This is my server config:

port 1194
proto udp
dev tap0

ca      /etc/openvpn/easy-rsa/keys/ca.crt
cert    /etc/openvpn/easy-rsa/keys/server.crt
key     /etc/openvpn/easy-rsa/keys/server.key
dh      /etc/openvpn/easy-rsa/keys/dh2048.pem

# brtctl upscript
script-security 2
up /etc/openvpn/up.sh

tls-server
server-bridge

keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3

The server is running on a Debian machine running in network A, the client is running on a OpenWRT router in network B. On network A, the tap0 interface is bridged with the local network, containing a DHCP server and a gateway to the internet. On network B, the tap0 interface is bridged with a separate network without DHCP-server or internet access. The idea is that the OpenVPN tunnel provides internet access for network B.

In this setup, the OpenVPN server doesn't allocate IP addresses for use by the clients. Instead, it just lets the DHCP server in the local network deal with that. This works because this is a bridged (TAP), not routed (TUN) setup.

So, DHCP does work over the tunnel. The clients on network B's side get their IP addresses directly from the DHCP server on network A's side. The problem is that it looks like the default gateway gets stripped from the DHCP reply, because it is empty on the machines on network B.

For example, this is what I get on a Windows client connected to network B:

Ethernet adapter Ethernet:

   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 192.168.2.123(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Lease Obtained. . . . . . . . . . : vrijdag 25 juli 2014 22:49:38
   Lease Expires . . . . . . . . . . : zaterdag 26 juli 2014 10:49:38
   Default Gateway . . . . . . . . . :
   DHCP Server . . . . . . . . . . . : 192.168.2.1
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

I found this: https://community.openvpn.net/openvpn/ticket/312#comment:3

This suggests that this is documented behavior, but I don't know how to disable this. I tried using the directive route-nopull on the client-side, but it doesn't appear to have any effect.

Also, I can't use redirect-gateway directives since I need to get the gateway right on the machines bridged with the OpenVPN client's tap0 adapter, not on the OpenVPN client itself.

My client-side config as follows:

config openvpn sample_client
    option enabled 1

    option client 1

    option dev tap

    option proto udp

    list remote "server.com 1194"

    option resolv_retry infinite

    option nobind 1

    option persist_key 1
    option persist_tun 1

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

    option ns_cert_type server

    option comp_lzo yes

    option verb 3

    option route-nopull 1

Keep in mind that is in OpenWRT's UCI format.

EDIT:

Just found this in the logs:

daemon.notice openvpn(sample_client)[5062]: Extracted DHCP router address: 192.168.2.1

This is exactly the behavior I want to disable.

Also found this:

If --server-bridge is used without any parameters, it will enable a DHCP-proxy mode, where connecting OpenVPN clients will receive an IP address for their TAP adapter from the DHCP server running on the OpenVPN server-side LAN. Note that only clients that support the binding of a DHCP client with the TAP adapter (such as Windows) can support this mode. The optional nogw flag (advanced) indicates that gateway information should not be pushed to the client.

Interesting. I did not set nogw. Could it be that is is implicitly set or something? Can I 'unset' it explicitly?

EDIT: Found this: https://forums.openvpn.net/topic13494.html
Someone with the same problem, thread from a year ago. No answers.

score 4 · Answer 1 · answered Aug 28 '16 at 07:18

4

According to OpenVPN documentation
server-bridge is a shortcut expression for

mode server
tls-server
push "route-gateway dhcp"

and

server-bridge nogw is a shortcut expression for

mode server
tls-server

Interestingly push "route-gateway dhcp" activates a DHCP-proxy that stripes out the default gateway option in DHCP response from the original DHCP server. This can be seen in OpenVPN log
daemon.notice openvpn[4879]: Extracted DHCP router address: a.b.c.d

Your solution would be to use server-bridge nogw and the DHCP response contains the default route option again.

answered Aug 28 '16 at 07:18

bjmi

151
4

Thanks. I understood exactly the opposite for the `nogw` option... – Ludovic Kuty May 08 '19 at 16:00
Excellent, this should be added to the docs at https://openvpn.net/community-resources/ethernet-bridging/ – Jasper Jul 09 '19 at 12:26

score 1 · Answer 2 · edited Jun 11 '20 at 10:02

1

Just had this problem myself and found this, without a useful solution. After a few hours i figured it out!

Just use this:

mode server

tls-server

and remove:

server-bridge

And the DHCP will pass directly to the client!

edited Jun 11 '20 at 10:02

Community

1

answered Jun 11 '15 at 14:53

Daniel

11
2

I added the "mode server tls-server" to my configuration (advanced; custom-configuration on tomato router) and this did in fact remove the stripping of the Gateway from the DNS response from my "vpnserver" router's DHCP response. Now, I have a virtual wifi on my "vpnclient" router that is bridges to my TAP interface on the "vpnserver" and I get a DHCP address from the VPN server (eithernet bridged) Thank you. – cgseller Jan 23 '19 at 02:53

score 0 · Answer 3 · edited Jul 26 '14 at 02:38

0

Use this for DHCP over OpenVPN (in server.conf):

server-bridge 172.18.100.100 255.255.0.0 172.18.100.105 172.18.100.250

Where:

172.18.100.100 is the IP of the OpenVPN server
172.18.100.105-172.18.100.250 is the range of Client IPs

And you will also need this on the OpenVPN (server.conf):

push "route 172.18.0.0 255.255.0.0"

That's about it. Afterwards, you only need to forward all traffic through one gateway (Server's IP) if you want to get outside from private network (on the client).

edited Jul 26 '14 at 02:38

masegaloeh

17,978
9
56
104

answered Jul 25 '14 at 21:27

Zatarra

407
3
5

Thanks for you answer, but that's not what I want. This doesn't use OpenVPN in DHCP relay mode; instead it configures OpenVPN to give out IP addresses instead of the DHCP server. I explained in my question that I don't want that. Besides, I'm using bridging (tap), not routing (tun), so I don't need the `route` directive and I don't need to forward any traffic because traffic doesn't flow through the server; tap0 is bridged to the LAN on the server side. – Compizfox Jul 25 '14 at 21:52

c4f4t0r · Answer 4 · 2014-07-25T22:05:27.830

0

the openvpn server-bridge options is used for bridge mode, you got two options use a separate dhcp server or the server-bride option

  https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

If i have a openvpn server in my subnet 192.168.122.0/24 i can use server bridge in this way

  #ip of my vpn server 192.168.122.9
  #vpn client ip pool
  server-bridge 192.168.122.9 255.255.255.0 192.168.122.20 192.168.122.40

In this way my vpn client gets on ip address in the remote subnet without use the remote dhcp server

edited Jul 25 '14 at 22:05

answered Jul 25 '14 at 22:00

c4f4t0r

5,149
3
28
41

OK, I explained in a comment to the (same) answer above that this isn't really a solution but rather a workaround, but say that I'm going to use this. How do machines bridged with the OpenVPN client (on network B) get an IP address? Remember, the only VPN client is running on the router on network B's side. On network B, there are a bunch of clients, bridged with network A through the OpenVPN tunnel, that are supposed to get a DHCP lease from the DHCP server on network A. – Compizfox Jul 26 '14 at 16:06

Gateway gets stripped from DHCP Reply through OpenVPN tunnel

4 Answers4