OpenVpn 2.3.2 removing DHCP default gateway in tap mode

joonaja

Hello!

My bridging network worked fine untill I upgraded to 2.3.2 version. After that I got "Extracted DHCP router address: *.*.*.*" warnings all over the place and branch offices connection failed miserably. Any pointers?

eibgrad

Wow, 18 months and no replies for what you'd think would be a serious problem for many ppl. I’m running 2.3.6. So no progress since at least 2.3.2.

Folks, is this a bug or a feature? Because if it's the latter, I don't get it. I assume the OP (and others I see complain about this problem on other forums) are trying to do like me. We have OpenVPN client established on some device, say a router, in bridge mode (tap). And we have that bridged to the LAN/WLAN interfaces. And now we'd like to have clients behind that device be configured via DHCP requests to the remote network made available over the tunnel. But for some odd reason, the default behavior is to STRIP the default gateway from the DHCP response, making internet access impossible.

Now according to the OP this worked as he/I wanted at least sometime before 2.3.2 (can’t vouch for that since I just discovered the problem myself). And either someone introduced a regression (i.e., bug), or else someone made a command decision that this behavior should be changed (not sure why). At the very least, I ‘d expect to be able to disable it.

So being curious (and desperate), I looked around the documentation and found this:

--server-bridge ['nogw']
A helper directive similar to --server which is designed to simplify the configuration of OpenVPN's server mode in ethernet bridging configurations.

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.

Hmm, looks promising, never noticed it before, but then I realize I don't have 'nogw' specified anyway. But it strongly suggests that providing a gateway IP is supposed to be the default. So what gives? Is this a bug? Because right now ppl like me are stuck. And apparently others have been stuck for quite a while. Not unless we resort to static IP configurations, which will be a problem in itself.

Traffic

I have just now setup a bridged VPN with transparent dhcp ..
@ eibgrad: what exactly is it you cannot do ?

OpenVPN 2.3.6 (server:linux client:windows)
DHCP Server on server side router
Using: --server-bridge [no parameters]

eibgrad

UPDATE: Well I got a little more curious (and frustrated) and decided I'd try the following directive anyway:

server-bridge 'no-gw'

To my surprise, now it does NOT strip the gateway! LOL So the 'no-gw' option means you *will* get a gateway (it won't be stripped). Go figure.

eibgrad

Traffic wroteI have just now setup a bridged VPN with transparent dhcp ..
@ eibgrad: what exactly is it you cannot do ?

OpenVPN 2.3.6 (server:linux client:windows)
DHCP Server on server side router
Using: --server-bridge [no parameters]

Thanks for the reply.

I've setup an OpenVPN client bridged (tap) tunnel on my dd-wrt router to a remote OpenVPN server, which works. I've also bridged the tap interface to the LAN/WLAN interface (br0) and disabled DHCP on that router so that when clients behind the router make their DHCP requests, it flows up the remote side of the tunnel for configuration. But either the OpenVPN client or server is stripping the default gateway out of the return data from DHCP. So those clients don't have internet access.

As luck would have it, just before you responded, I discovered that using server-bridge 'no-gw' works the opposite of what I thought; specifying it means it will NOT strip the default gateway from the DHCP response. That seems counter-intuitive to me. Perhaps they could have chosen a better name. I know others are just as confused because apparently they didn't think to use it either.

http://serverfault.com/questions/615597/gateway-gets-stripped-from-dhcp-reply-through-openvpn-tunnel

Anyway, now it’s working the way I want.

Traffic

eibgrad wrotedecided I'd try the following directive anyway:

server-bridge 'no-gw'

To my surprise, now it does NOT strip the gateway

to my surprise:

--server-bridge nogw
.. or ..
--server-bridge 'nogw'

works !

but:

--server-bridge no-gw
.. or ..
--server-bridge 'no-gw'

result:
openvpn[15653]: Options error: Unrecognized option or missing parameter(s) in /etc/openvpn/taps_14950u.conf:22: server-bridge (2.3.6)

So get your syntax correct.

eibgrad wroteI discovered that using server-bridge 'no-gw' works the opposite of what I thought

Perhaps you misunderstood the no gateway option:

For example, server-bridge 10.8.0.4 255.255.255.0 10.8.0.128 10.8.0.254 expands as follows:

mode server
tls-server

ifconfig-pool 10.8.0.128 10.8.0.254 255.255.255.0
push "route-gateway 10.8.0.4"

push the gateway that is the OpenVPN server.

The Manual wrote In another example, --server-bridge (without parameters) expands as follows:

mode server
tls-server

push "route-gateway dhcp"

"dhcp" means the route gateway is the server side real dhcp server (commonly: the server side default gateway).

The Manual wrote Or --server-bridge nogw expands as follows:

mode server
tls-server

so no gateway is pushed to the client ..

Basically .. the nogw option disables the server push "route-gateway x ..

eibgrad wrotespecifying it means it will NOT strip the default gateway from the DHCP response

Not sure what you were having trouble with .. but OpenVPN is not "stripping" anything out of the dhcp protocol ..

eibgrad

I think you’re missing the point (or at least one of us is). I have the following directives in my server config:

daemon
server-bridge
proto udp
port 33883
dev tap22
comp-lzo adaptive
keepalive 15 60
verb 3
push "dhcp-option DOMAIN yankee"
push "dhcp-option DNS 192.168.66.1"
status-version 2
status status

# Custom Configuration
ca /jffs/openvpn/server/ca.crt
cert /jffs/openvpn/server/server.crt
key /jffs/openvpn/server/server.key
dh /jffs/openvpn/server/dh2048.pem
server-bridge
duplicate-cn

It has “Custom Configuration” as a comment because everything before that comment the router auto-populated. Everything after it I added as custom configuration changes. That’s probably neither here nor there, but I wanted to provide a complete picture. The key directive here is server-bridge.

To restate the situation, I’ve setup the OpenVPN client on a dd-wrt router. The *ONLY* client of the OpenVPN server in this entire configuration is the router. In fact, I don’t even care all that much if the router has internet access, has a DNS server, or much of anything else. Its only job is to get the tunnel established on behalf of the wired and wireless clients behind the router. So however I may have correctly or incorrectly interpreted the server-bridge directive and all its many options, the fact is, left solely as “server-bridge” it’s connected and has a valid IP and subnet mask from the remote network. It works just fine. We’re ready to rock and roll.

Now behind that router are wired and wireless clients which are configured to use DHCP. But I’ve disabled DHCP on that same router (normally it would be enabled). And I’ve bridged the router’s OpenVPN client to the same LAN interface used by those wired and wireless clients. So now when those wired and wireless clients make a DHCP request, all I want them to do is have those requests pushed over the tunnel, answered by the remote network’s DHCP server, and returned. IMPORTANT: At no point do any of these wired and wireless clients ever become OpenVPN clients themselves. NEVER! They’re merely using the tunnel established by the one and only OpenVPN client; the router.

But there’s a problem. Unless I specify server-bridge ‘no-gw’, either the OpenVPN client or OpenVPN server is stripping the default gateway from the remote network’s DHCP server response! In fact, it actually says that in the OpenVPN log! And once the DHCP response gets back to those wired and wireless clients, they have no gateway specification, it’s blank, and hence no internet access.

IOW, OpenVPN is mucking w/ traffic between an established OpenVPN client and the OpenVPN server to which it is connected. Why? I say again, these wired and wireless clients are NOT OpenVPN clients. Anything that’s passed between an established OpenVPN client and OpenVPN server connection should be left alone. But it’s clearly messing w/ the traffic; it even reports it in the log. And I don’t understand why. I *could* understand why that might be the case if those wired and wireless clients were trying to establish themselves as OpenVPN clients. Now all the details about server-bridge and all its many options come into the picture. But that’s simply not the case. Once the router has setup itself as an OpenVPN client to the OpenVPN server, it should fade into the background, become completely transparent. It should be as if there was an Ethernet cable running from the router and over to the OpenVPN server and whatever my wired and wireless clients choose to do (including issue DHCP requests) should be none of its business.

I’m just stumped as to why OpenVPN is mucking w/ my traffic given this scenario. It’s really a very simple configuration. And as I just discovered, if I change that directive to server-bridge ‘no-gw’, then like magic, everything is right w/ world. It no longer mucks w/ the traffic, the gateway field in the DHCP response is left alone. My wireless and wireless clients get a gateway IP from the remote network's DHCP server.

I’m fully prepared to be corrected in my understanding of what’s happening. I just want someone to enlighten me as to what it is that I’m missing here.

eibgrad

Here’s the OpenVPN client log from the router when I only have “server-bridge” specified (no ‘no-gw’ option).

https://app.box.com/s/fhr9etav95gt1k7exzgk

And the result of the DHCP configuration on my iPod Touch.

https://app.box.com/s/gftqtyzvt5ulk25p79po

eibgrad

P.S. Sorry about the references to no-gw, that's just a bad habit when I'm typing, it's actually always been nogw in the config file.

eibgrad

deleted deleted

eibgrad

Ok, I’m pretty sure I finally figured out what the problem is. You truly do learn something new every day in this business.

Turns out that when I specified server-bridge (no arguments), and it was supposed to use the DHCP server of the remote network, the DHCP server was NOT responding. And looking more closely at the OpenVPN docs, I do see 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.

So since the router is a Linux client, I assume that’s why DHCP wasn’t working. The only configuration that works under Linux (at least for me) is a complete server-bridge directive and arguments.

server-bridge 192.168.66.1 255.255.255.0 192.168.66.240 192.168.66.249

That one simple oversight led to this entire chain of events.

Still, even if the OpenVPN client failed to initialize w/ IP, that shouldn’t have caused this bizarre behavior. Technically, I shouldn’t even have to initialize IP on a bridge. And my own usage of it demonstrates this. It wasn’t as if the tunnel wasn’t usable. But OpenVPN just goes haywire if it fails to initialize the tunnel w/ IP. Then you get this nonsensical stripping of the gateway IP from any subsequent DHCP request that happen across the tunnel.

And I know I’m not alone:

https://forums.openvpn.net/topic13814.html

As the OP of that of that link said, what if you don’t know ahead of time the IP network you may be connecting to, or even if you do, you don’t want to be self-assigning static IPs from someone else network; that’s sure to cause problems.

Anyway, perhaps all this will help someone in the future. I just know I’m not the first or the last to run into it.

Traffic

The OP of this thread: https://forums.openvpn.net/topic13494.html#p32056 - simply failed to post an answerable query as there was not enough detail. It was also posted Aug-2013, a year before I join this forum.

This thread: https://forums.openvpn.net/topic13814.html - Looks like the OP is trying to do something impossible:

xenix wroteThe problem is that my client devices connected to DD-WRT router do not receive gateway address from 10.197.255.254 DHCP server. I would for example simply set server-bridge 10.197.255.254 255.255.0.0 10.197.0.1 10.197.255.253 and it would work, BUT since I do not have control of 10.197.255.254 server (it belongs to my ISP) I can't do that to avoid IP conflicts

It appears xenix wants to solicit DHCP configuration from the ISP DHCP server .. which, unless xenix has a very strange contract with his ISP, is not possible.

Now your setup:

eibgrad wroteNow behind that router are wired and wireless clients which are configured to use DHCP. But I’ve disabled DHCP on that same router (normally it would be enabled). And I’ve bridged the router’s OpenVPN client to the same LAN interface used by those wired and wireless clients. So now when those wired and wireless clients make a DHCP request, all I want them to do is have those requests pushed over the tunnel, answered by the remote network’s DHCP server, and returned. IMPORTANT: At no point do any of these wired and wireless clients ever become OpenVPN clients themselves [†]

However, I need to point out that:

The Manual wroteIf --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

[†] which does not include other client LAN hosts which are not OpenVPN clients.

So I have no idea what you have done .. but, hey, if it works then it works ..

eibgrad

Traffic wroteHowever, I need to point out that:
The Manual wroteIf --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
[†] which does not include other client LAN hosts which are not OpenVPN clients.

So I have no idea what you have done .. but, hey, if it works then it works ..

Exactly my point. My one and only OpenVPN client (which is the router) should be getting an IP assignment from the DHCP server of the remote network (thanks to DHCP-Proxy), since server-bridge has no arguments. But that's not happening. An IP never gets assigned. So it remains uninitialized for IP. And yes, all the wired and wireless clients behind the OpenVPN client are not themselves OpenVPN clients. So I don't expect the DHCP-Proxy feature to be invoked. But I do expect that if those same non OpenVPN wired and wireless clients issue a DHCP request of their own, that the VPN shouldn't mess w/ it.

That's the confusion here. You’re reading this as if I expect the DHCP-Proxy feature (which only affects OpenVPN clients) to be used/invoked by the non OpenVPN clients behind the router. I don't. As you said, they're not OpenVPN clients. But I do expect that ANYTHING those same non OpenVPN clients send over the tunnel is not messed with, INCLUDING any DHCP requests they may generate. DHCP-Proxy is simply not relevant in those cases. It's just ordinary tunnel traffic. Yet the VPN *is* messing w/ those DHCP packets. For all intents and purposes, it's treating those DHCP requests as if they WERE being handled/processed by the DHCP-Proxy! That imo is the bug. And the only way I found to get around this bug is to specify a complete server-bridge directive so that the OpenVPN never fails to initialize IP. For some reason, if the OpenVPN client fails to initialize w/ IP (which I said before shouldn’t even be necessary for a bridge), then it triggers this bizarre behavior in OpenVPN were it starts messing w/ ANY kind of DHCP traffic, even from non OpenVPN clients behind the actual OpenVPN client.

I know it’s confusing to just read about what’s happening here, but I can tell you w/ certainty that’s the case. I can reproduce the problem at will.