How to block DHCP requests over VPN

I’m wondering what the best way to block DHCP requests from traversing a VPN?

I understand I can have a firewall rule on each router that blocks ports 67-68 traffic on the wireguard interface, but I’m wondering if there is a more efficient way?

Thanks.

Disconnect the VPN

Sounds like an incorrectly configured setup.

Yes, and no… The user, as usual, do not provide any relevant detail, like VPN type, and the other needed details for reply on correct way.

What odds will you pay out??

I have clearly caught you both on a good day :smiley:

Wireguard VPN
hEX and hAP devices
6 locations, each running DHCP servers on their “bridge” interfaces (which do not include their WAN ports (typically ether1))

Certainly could be that DHCP requests are by default not passed by wireguard interfaces.

The reason I’m asking is because I have 2 locations where the edge router is a Ubiquiti UDM (running DHCP server) and I noticed some clients connected locally to the UDM had gotten a DHCP address from a hAP remotely connected via the Wireguard VPN.

So, it is certainly possible that the issue is that the DHCP request came in on the Wireguard interface, entered the LAN, was responded to by the UDM, etc.

If I understand the meaning, I prefer not to bet… :laughing:

Welldone, keep @anav guide you :wink:

No the dhcp requests should not be going through.
It is true that all MT routers have one flat network subnet associated with the bridge ( no vlans? )

Sounds like you have probably made a mistake of using perhaps too too similar subnet structures? ( duplicate )??

Cannot help with ubiquiti shenanigans…
If none of the other subnets on the MT routers are experiencing the same phenomena!!!

I ran a packet sniffer overnight collecting all port 67 and 68 traffic on all routers.

Sure enough, I found a few packets destined for port 68 that traverse the WG connection and originate from the Ubiquiti UDM and destined for my main work computer (very odd, as that computer does not run a DHCP server).

It’s not important – I’m just curious.

192.168.0.1 is the UDM
192.168.0.11 is the hEX behind the UDM that provides the WG connection
192.168.2.22 is my main work computer



Capture2.JPG
Capture.JPG

Src port 7932???
Usually are port 68…

It’s a scan of some form…

The wireguard is the only tunnel?


Server???

But run a DHCP Client?!




There can be various types of VPNs,
but in principle there are mainly two: L2 VPN and L3 VPN.
In case of L2 VPN, the interface of the VPN is like a network cable, it connects the two networks transparently when using a bridge.
In case of L3 VPN, the interface only carries IP traffic from one point to another, and must be mapped to routes.

Over L2 VPN normally anything broadcast, such as DHCP, from one network is communicated to the other.
Over L3 VPN there is normally no broadcast traffic, and some services such as DHCP do not work.

If there is no need to see both networks as if they were a large LAN, but it is enough that the IPs can be reached (via local DNS or “by hand”),
the L3 VPNs are more performing because they have to pass less data between the nets, allowing for a higher MTU (and therefore MSS).

The MTU (and MSS) has to be reduced in any case anyway,
because whatever VPN you use adds an overhead that reduces the classic MTU of 1500*** (MSS 1460) to a smaller value
(for example, if I remember correctly, wireguard uses ~80bytes, so the wireguard MTU must be at least 1420 (and the MSS max 1380))
[*** some provider can provide more, but must be considered both sides]

If you use L2TP over wireguard, you have to subtract other 40 bytes,
so for the other devices the L2 MTU usable on that tunnel must be 1500 - 80 - 40 = L2 MTU of 1380 (and for IP, L3 MTU 1366 and max MSS of 1326)

(I wrote from memory, I hope that the counts are right.)

Beyond my scope of knowledge, just to state I dont think its anything the MT is doing.

Yes, there is some program on 192.168.0.1 that scans or other things (I think)…

I usually in such situations, I block forwarding on bridge udp ports 67-68. Then packets from other DHCP servers are not forwarded through the bridge and everything is stable.
Screenshot_1.jpg

What do you mean in such situations? When does this occur?

When several offices are connected into a single network.
The VPN interface is added to the bridge
PS If a wrong DHCP server or client appears on one of the router ports in one of the offices, it will not affect the entire joined network.

Ahh okay, we dont attach Wireguard to the bridge so never see this…

Wireguard can’t be added on the bridge, only the L2 tunnel used can be put on bridge.
Wireguard is one L3 tunnel, so, only IPs and routing…

You can put on bridge only the (useless) tunnels added to wireguard extremes,
for L2 connectivity betwen the two LANs (with a bottlenek of only 1380 Bytes over 1500 standard…).

Is why DHCP Servers on both sides are mixed and create conflicts.
Two things can stop DHCP Servers mixing: rules on bridge that stop dhcp/bootp services or configure correctly the routing for wireguard interfaces,
instead of uselessly use L2 tunnel (EoIP, GRE, L2TP, etc.)

Yup above my head, same as running an internal PPP server, I cannot grasp how one can have an ethernet port with a LAN subnet also being used for ppp. Boggles my mind, due to the fact anyone connecting to that subnet will get DHCP from that subnet so how supposed to get a PPP connection…sigh…