DHCP option ROUTERS gets dropped on packets not targetting the OpenVPN client

[moviuro]

Hi,

Issue:
If I read this correctly ​https://github.com/OpenVPN/openvpn/blob/master/src/openvpn/dhcp.c, OpenVPN simply scratches away the ROUTERS option of DHCP replies, regardless of their destination.
The reason for dropping ROUTERS from a DHCP replies makes perfect sense on the VPN client itself, as the new defualt route would actually be inside the VPN link, thus breaking the client's connectivity.
However, OpenVPN drops the ROUTERS option even on packets that are not meant for the machine OpenVPN runs on. This behavior is not desirable in my setup :

(tap) OpenVPN Server; DHCP server (10.20.0.1/24)
  ^
  | VPN
  v
(tap) OpenVPN Client; uses DHCP but drops ROUTERS (10.20.0.2/24) (default via ISP GW)
 | bridge
(eth)
  | RJ45
(eth) Laptop; DHCP client; needs DHCP and ROUTERS option (10.20.0.100/24)
      Expected: default via 10.20.0.1
      Actual:   no default route

The OpenVPN client bridges its tap interface with an ethernet interface, allowing an other device to magically drop into the VPN.
As this client launches its DHCP request, it gets to the OpenVPN server (thanks to the bridge).

Proposed solution:
Check the destination of the DHCP reply packet being rewritten:

• If the DHCP reply targets the OpenVPN client, then rewrite it as usual
• Else, let the packet through without harming it

(I know 0 C, so can't help produce a patch)

[Gert Döring]

Interesting issue you're bringing up. As david already suggested, going to a routed setup might solve this in the short run, but as long as we offer bridged, it should be working :-) - need to look into it, eventually. But it won't happen in the *near* future (as the routed-setup workaround exists)

[mario.lipinski]

We were running into exactly the same issue. Eventually we ended with compiling an OpenVPN version with a commented section where dhcp_extract_router_msg is called.

As far as I understood, this should not be called when route-gateway dhcp is set, but I did not get a working configuration either while experimenting with this option.

I'd appreciate if this could be fixed in OpenVPN.