Does anyone know the best way to drop DHCP requests and offerings across an EoIP connection?
I assume a firewall rule. If so, by port? Or is there a better way?
I have a bunch of EoIP interfaces, and they are all members of the bridge.
Thanks.
/interface bridge filter
add action=drop chain=forward comment=dhcp dst-port=67-68 ip-protocol=udp mac-protocol=ip
Use bridge filter. Also you may try to use a specific in/out interface in this rule.
My concern is that the bridge has many interfaces, and I need to block DHCP on only some of which.
Perhaps I am misunderstanding, but the code above will block all DHCP traffic across interfaces in the bridge, correct?
Make an interface list for dhcp-enabled or dhcp-disabled interfaces and create an appropriate rule for the specified interface list (rule template above).
That works – thank you.
When you do have “a bridge with many EoIP interfaces”, and it is not some temporary solution e.g. to support a move of equipment to another location or some other kind of migration, you REALLY need to re-think your network design!
This is not something you want to have in the long run.
Hmm…
It seems the filter is working:
forward: in:eoip-tunnel-to-212 out:ether4, connection-state:invalid src-mac 18:fd:xx:xx:xx:xx, dst-mac ff:ff:ff:ff:ff:ff, eth-proto 0800, UDP, 192.168.2.2:67->255.255.255.255:68, len 328
But I still get a log entry from the DHCP ALERT:
dhcp alert on bridge: discovered unknown dhcp server, mac 18:FD:xx:xx:xx:xx, ip 192.168.2.2
I added the DHCPdisabled interface-list to the filter out-interface but it did not fix it:
/interface bridge filter
add action=drop chain=forward comment="DHCP Drop " dst-port=67-68
in-interface-list=DHCPdisabled ip-protocol=udp log=yes mac-protocol=ip
out-interface-list=DHCPdisabled
I think the fact that the “rogue” dhcp server on 192.168.2.2 can be reached over the Wireguard interface is the cause of the problem.
So I added this:
/interface list member
add interface=355-WGhEX list=WG
add action=drop chain=forward comment="DHCP Drop " dst-port=67-68
in-interface-list=WG ip-protocol=udp log=yes mac-protocol=ip
out-interface-list=WG
But that did not stop the rogue DHCP errors.
So I ran the sniffer and I see that the packets on port 68 from the external (i.e., rogue) dhcp server are coming in on (1) the bridge, (2) eoip-tunnel-to-212, and (3) ether4.
So, I think the packets are getting via ether4.
This hex is connected to behind the border router (a Ubiquiti UDMpro) and acts as a Wireguard and DHCP server and EoIP host. Those are it’s only 3 functions (besides letting me play and learn). It is connected to the lan on ether4. I don’t understand how the packets are not being blocked by the bridge filters in place.
The bridge filter also uses chains, so if you block the server responses in forward, the Mikrotik itself will receive them, whilst other devices on the same bridge will not.
Does this mean that using a bridge filter will not block traffic to/from ports 67/68 getting to/from the Mikrotik device?
I tried an input firewall for those ports, from various interfaces, and then from 192.168.2.2 and the rogue dhcp server was still detected.
The input chain should block it, but given how the DHCP is hooked into the networking stack (e.g. you cannot block DHCP using IP firewall), I’m not sure whether blocking it is sufficient to prevent the DHCP stack from seeing them already on the member ports of the bridge. I’d say try with some other UDP packets (like DNS) to see whether there is a difference.
I created 2 bridge filters: One INPUT and one FORWARD to block ports 67-68 on the interface list DHCPdisabled.
It appears that the DHCP servers from each location (with MT device at each location) broadcasts (i.e., 255.255.255.255) on the bridge the DHCP requests that come into it. The bridge filters catch these.
I obviously don’t have a firm grasp of what is going on, but I am concerned about this unnecessary DHCP traffic over the Wireguard and/or EoIP connections.
The issue of the a DHCP ALERT perists – it appears that neither bridge filters nor IP firewall rules block the DHCP ALERT facility’s functionality.
That is why I am concerned about your network design involving many EoIP connections in a bridge.
This DHCP issue is only the first one you noticed. But there will be more!
Abandon this path now that it is still possible.
Abandon EoIP connectivity?
Stay with Wireguard?
The impetus for EoIP was (besides learning and experimenting) to have another way to access the router when other ways fail (high importance), to see the MT devices in Winbox (very low importance), and (not yet implemented) being able to map drives across these links (low to medium importance). So, the only high importance reason is to have another way to access to the devices.
Advice?
You can use EoIP just like any other L2 (“ethernet-like”) interface without adding it to a bridge. And as an alternative (to Wireguard) way to access devices, there is also SSTP, L2TP/IPsec*, IPIP/IPsec* or even bare IPsec*… those marked with an asterisk can be set up using a pre-shared key, i.e. without certificates if that scares you.
Would you mind expanding a little on keeping EoIP active but not added to the bridge?
How would it be used and useful? How can I use it another way to access the router when there is a problem?
Think of the EoIP tunnel the same way like of a loooong Ethernet cable connecting two Ethernet interfaces on the two routers. So same steps would be required to use them as a backup communication channel. For example do not make either of the Ethernet interfaces a member port of any bridge, just assign to each of them a static IP address from the same subnet. And don’t forget to adjust your firewall rules so that packets coming that way were allowed to establish a management connection to the router (ssh, Winbox, http(s)). Or you can activate romon which doesn’t care about bridges and VLANs and uses just MAC addresses and Ethertype.
Other than that, breaking a single VPN tunnel is just one of many ways how to lock yourself out from a router. In another words, adding another VPN technology is a good way to protect yourself from external influence (like an ISP that starts to block Wireguard), but it only has a limited impact if you are going to experiment with any other settings than the Wireguard ones themselves. So there is the Safe Mode, but some changes interrupt the connection for so long that the Safe Mode reverts them although they actually did not cause a lockout, ane even worse, I have already encountered a few cases when Safe Mode did not revert the changes properly and I had to drive or send someone there. So ever since then, if I suspect that the change I am going to do might not come out right, I use scheduled scripts to revert it in about 20 minutes.
Sure it is convenient that EoIP transports L2 and thus it may be attractive that routers appear in the Neighbors list or in RoMON, but you should be aware that EoIP is still dependent on IP and so when you do something that would make your router inaccessible in an IP network, would probably still make it inaccessible over EoIP!
So it will probably not bring you much to keep an EoIP network just to have more reliable remote access.
And it has lots of disadvantages, especially when you join networks that were separate (e.g. LAN at different locations) via EoIP.
You already became aware of the problem that DHCP travels the link and confuses everything, but in fact that is true for EVERY protocol that uses broadcast or multicast.
So you will cause a lot of confusion in your network and probably also performance problems (because all broadcast and multicast traffic is unnecessarily bridged between the networks).
I recommend staying with an IP routing design, no matter what VPN protocol you use (some of them support both IP (L3) and ethernet (L2) level).
To improve redundancy you can select tunnel types that do not use subnets for their endpoint definition but are “plain tunnels” that present as an interface pair over which you can route anything. So that would be GRE/IPsec, IPIP/IPsec, L2TP/IPsec but it can also be Wireguard with 0.0.0.0/0 as subnet spec.
Then you can use an autorouting protocol like BGP or OSPF on top of the mesh you create with that.
Then if some tunnel fails, the traffic can be routed along another path.
That extra path can also be made available using different internet connection technology, e.g. in our branch offices where only a single main internet connection is available, I added a USB LTE stick to provide backup via LTE, and it participates in the autorouting so when the main (DSL or fiber) connection fails I can still access the remote router to investigate.
on top of your head, in which cases Safe Mode didn’t revert back.
Some change in vlan over wireless… sorry, I don’t remember exactly, it’s been years ago.
… but the other direction of the problem is much worse.
I really would like to set parameters like a connection timeout and the behavior on “unreachable” replies.
When you have a complex network (as described above) and some changes are made to tunnels, it may take some time before the re-routing is complete and in the meantime the router reverts the changes.
It should be possible to set in a router (and that should be communicated to winbox as well) how long the link can be down before it gives up and reverts (and before winbox disconnects).
I would want to set that to a couple of minutes.