DHCP Relay and Required Firewall Rule

dorian · Wed May 02, 2018 7:39 pm

Hi all,

we have a setup where use a Mikrotik router at a remote site and relay DHCP over an IPsec tunnel to a central DHCP server in the main office. Everything works fine, but today I noticed that we don't actually have any appropriate rule in the firewall's input chain—at the same time there is a catch-all DROP at the end of the chain.

I'd imagine that you'd need something like

chain=input protocol=udp in-interface=lan-interface dst-port=67 action=accept

to make sure that the DHCP discovery and request messages can be received and relayed by the Mikrotik router, but it works without such a rule.

Could it be that activating DHCP relay on a given interface automatically inserts an invisible corresponding rule into the filter list? If not, how can our setup actually work as it is?

Thanks for any pointers & best regards,
Dorian

maxsaf · Wed May 02, 2018 8:14 pm

Do you have Bridge-Settings-UseIPFirewall enabled? What about UseIPFirewallForVLAN option?
What about Bridge-Filters?

dorian · Wed May 02, 2018 11:03 pm

The input interface is indeed a VLAN on a bridge. No bridge filtering is active, however ("Use IP Firewall" and "Use IP Firewall For VLAN" are disabled). In any case, shouldn't all packets that are received by a process on the router traverse the INPUT chain?

sindy · Thu May 03, 2018 12:08 am

shouldn't all packets that are received by a process on the router traverse the INPUT chain?

They do - I've added a

action=log dst-address=255.255.255.255

at the top of

chain=input

in

/ip firewall filter

, and it does count and log DHCP packets and MNDP packets with broadcast destination. So I've started speculating that DHCP discovery packets might be treated as

connection-state=established

or

related

and thus handled by the usually present rule "accept established, related" - nope, they are regular

connection-state=new

as they should be.

So I guess you have some general "accept anyhing which comes via LAN" somewhere there.. can you publish your

/ip firewall filter export

after replacing eventually present public IPs with some made up ones?

dorian · Thu May 03, 2018 10:23 am

Here's the export. We have two VLANs on a bridge containing all LAN-facing ports, vlan60 (10.60.0.0/16) is internal while vlan99 carries guest WiFi traffic. We only do DHCP relay (to the DHCP server in the main office subnet 10.10.0.0/16) for vlan60, for vlan99 it's handled by the WiFi controller. For some reason the rules aren't sorted by chains, but there's not that many.

/ip firewall filter
add action=accept chain=output comment="IPsec to Main Office (ESP)" dst-address=<MAIN_OFFICE_IP> out-interface=ether01-gateway protocol=ipsec-esp
add action=accept chain=output comment="Allow established" connection-state=established
add action=accept chain=output comment="Allow related" connection-state=related
add action=accept chain=output comment="DHCP relay" dst-address=10.10.0.0/16 dst-port=67 protocol=udp
add action=accept chain=output comment="DNS queries to WAN" dst-address-list=init7-dns dst-port=53 out-interface=ether01-gateway protocol=udp
add action=accept chain=input comment="IPsec from Main Office (ESP)" in-interface=ether01-gateway protocol=ipsec-esp src-address=<MAIN_OFFICE_IP>
add action=accept chain=input comment="DNS Queries From Guest LAN" dst-port=53 in-interface=vlan99 protocol=udp
add action=accept chain=input comment="Allow ICMP from everywhere" protocol=icmp
add action=accept chain=input comment="Allow webfig from LAN side" dst-port=80 protocol=tcp src-address-list=LAN-Side
add action=accept chain=input comment="Accept SSH from everywhere" dst-port=22222 protocol=tcp
add action=accept chain=input comment="Allow established" connection-state=established
add action=accept chain=input comment="Allow related" connection-state=related
add action=drop chain=input comment="Drop policy input"
add action=accept chain=forward comment="Allow established" connection-state=established
add action=accept chain=forward comment="Allow related" connection-state=related
add action=reject chain=forward comment="Reject non-IPsec local traffic to WAN" dst-address=10.0.0.0/8 ipsec-policy=out,none out-interface=ether01-gateway reject-with=icmp-admin-prohibited
add action=accept chain=forward comment="Internet access for LAN side (including IPsec tunnel)" in-interface=vlan60 out-interface=ether01-gateway
add action=accept chain=forward comment="LAN access from IPsec tunnel" dst-address=10.60.0.0/16 in-interface=ether01-gateway ipsec-policy=in,ipsec out-interface=vlan60 src-address=10.10.0.0/16
add action=accept chain=forward comment="Internet access for Guest LAN, TCP Ports" dst-port=21,22,25,80,443,465,587,993,995 in-interface=vlan99 out-interface=ether01-gateway protocol=tcp
add action=accept chain=forward comment="Internet access for Guest LAN, UDP Ports" dst-port=500,1194,4500 in-interface=vlan99 out-interface=ether01-gateway protocol=udp
add action=reject chain=forward comment="Reject non-whitelisted connections from guest network" in-interface=vlan99 out-interface=ether01-gateway reject-with=icmp-admin-prohibited
add action=drop chain=forward comment="Drop policy forward"
add action=accept chain=output comment="Allow NTP" dst-port=123 protocol=udp
add action=accept chain=output comment="Allow ICMP" protocol=icmp
add action=accept chain=output comment="Accept HTTP out for update checks" dst-port=80 out-interface=ether01-gateway protocol=tcp
add action=drop chain=output comment="Drop policy output"

I can't really see which of the input rules would accept broadcast or unicast traffic to UDP port 67.

sindy · Thu May 03, 2018 10:38 am

It has already popped up 10 years ago with no clear outcome. I would suggest to send that to support@mikrotik.com for clarification.

dorian · Thu May 03, 2018 12:57 pm

It has already popped up 10 years ago with no clear outcome. I would suggest to send that to support@mikrotik.com for clarification.

Thanks for your support! The link you provided does not seem to work, do you mean viewtopic.php?t=14050?

It's interesting that this has been observed 10 years ago already

I might indeed try and contact Mikrotik to see what they have to say about it.

sindy · Thu May 03, 2018 1:03 pm

Fixed, I've copy-pasted a wrong browser form field and haven't noticed that. But yes, you've found the same topics.

I was dealing with another surprising behaviour of the DHCP server where server responses were not offered for inspection by IPsec policy and the answer from Mikrotik support was that it behaves like this for years. So it seems the DHCP server/relay is really hooked into the network stack very close to the wire and bypasses the firewall, most likely even the output chain as IPsec policy matching takes place after all firewall chains have been already passed.

pe1chl · Thu May 03, 2018 2:11 pm

The DHCP server uses a raw socket so it receives everything, unaffected by the firewall. So you don't require any input rule.
You can add an input rule for port 67 and it will match the traffic (counters increment) but it does not matter if you have accept or drop, the DHCP server (and the relay) will always work.
However, in the case of the relay you DO require appropriate forward firewall rules along the path to forward the traffic from the router where the relay is to the DHCP server.
This is UDP port 67 traffic as well.

sindy · Thu May 03, 2018 2:20 pm

@pe1chl, do you insist that the dhcp relay L3-forwards the very same packet received from client? In my understanding (and experience!), it generates a new one with a local source address, and only copies the information received in the packet from the client into that new packet, so the

output

chain applies, not

forward

.

pe1chl · Thu May 03, 2018 3:16 pm

Yes that is true on the router where the relay runs, but on the other routers between there and the DHCP server you need a forward rule.

pe1chl · Thu May 03, 2018 3:20 pm

Another remark: your style of using "code" to mark loose words of config info makes text very unreadable on the forum style I am using. It may be different on other styles.
I prefer the use of "bold", "italic" or "underline" for such things.
"code" is of course fine for entire-line or multi-line config fragments!

dorian · Thu May 03, 2018 3:32 pm

The DHCP server uses a raw socket so it receives everything, unaffected by the firewall. So you don't require any input rule.

That's it. Completely forgot that dhcpd needs to open a raw socket, so no chance for any firewall rules to apply. Thanks for all the feedback.

sindy · Thu May 03, 2018 5:17 pm

your style of using "code" to mark loose words of config info makes text very unreadable on the forum style I am using.

Holy sh.., thank you for letting me know. I was so happy to find out how to make it behave predictably with the default skin (Mikrotik default, not phpBB default as far as I understand) and it didn't come to my mind that it could be processed so differently by other skins. I first thought you had in mind some big difference in font size between highlighted text and keyword marked as code, but I could not imagine that each such word would create a whole code rectangle as this is what I have successfully suppressed in the (MT) default skin.

Sob · Thu May 03, 2018 7:30 pm

@sindy: For the record, your use of [code] looks broken in my favourite style (prosilver) too, but I must say that I like very much how it looks in default one, it adds a real professional touch. Too bad I don't like default style as whole, it's so white and I can't get used to it. I'd prefer if MikroTik tweaked other styles to behave like default one, but I'm not sure if they'd want to fiddle with them too much.

mischa01101 · Mon Apr 03, 2023 10:29 am

The DHCP server uses a raw socket so it receives everything, unaffected by the firewall. So you don't require any input rule.
You can add an input rule for port 67 and it will match the traffic (counters increment) but it does not matter if you have accept or drop, the DHCP server (and the relay) will always work.
However, in the case of the relay you DO require appropriate forward firewall rules along the path to forward the traffic from the router where the relay is to the DHCP server.
This is UDP port 67 traffic as well.

This advice is wrong for dhcp relay. You need a rule which accepts the request for port 67 udp.

DHCP Relay and Required Firewall Rule [SOLVED]

DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule [SOLVED]

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Re: DHCP Relay and Required Firewall Rule

Who is online