MX - Unicast RPF failures on DHCP

[RaphaelL]

Hi ,

We are running MXs in NAT mode under the 15.44 code ( yeah I know. ) 

On some sites we have machines that have issues getting IP from DHCP. 

We can see the MX dropping thoses packets with the event log : 

Documentation states : Special exceptions are made for DHCP discover messages and for traffic used to synchronize information between MXs in a NAT warm spare configuration.

https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/IP_Source_Address_Spoofing_Protecti...

Has anyone ever encountered issues with RPF ? We have 1000++ networks , I'm pretty sure that I can find couple other examples.

Yes upgrading to MX17 or MX18 is planned , but I don't see any mention of that behavior in the patch notes.

EDIT : 

This is a branch. The MX is configured to relay DHCP packets to a DHCP server in our DC over the S2S VPN. Setup is working fine for 99.9999% of our clients/workstation except some which seems to be sourcing the requests with an IP different from 0.0.0.0 as per the RFC.

Thanks ,

[alemabrahao]

It looks like L2 issue or DHCP issue. Who is your DHCP server?

[RaphaelL]

Same topology as the documentation.  MX receives the DHCP discover , but drops it.

[RaphaelL]

Wait.  Shouldn't DHCP discover packets be sourced with 0.0.0.0 ?  I might have to read the RFC again

 DHCP messages broadcast by a client prior to that client obtaining
   its IP address must have the source address field in the IP header
   set to 0.

https://www.rfc-editor.org/rfc/rfc2131

Well I think I found the issue.  Thoses machines are sourcing their DHCP discover with an IP different from 0.0.0.0.   Meraki support will confirm that. I will keep you guys updated. 

[rhbirkelund]

Wait - what? An MX doesn't forward DHCP between it's Internet port and LAN ports. The DHCP as shown in the drawing is only for the MX's Uplink. DHCP for clients downstream is handled by the MX itself. You'll need to configure a DHCP server on the VLANs configured on the MX.

[RaphaelL]

DHCP is over the S2S VPN. This is a spoke.

[rhbirkelund]

Ah - that was not clear.

Did you configure DHCP relay?

[RaphaelL]

Yes. This setup is currently working for all clients and all sites.

Sorry for the confusion. I will edit the first post. 

[RaphaelL]

I was right ! 

The IP source address spoofing protection is expected to block traffic from a device when it see's a source IP that does not match a known configured VLAN/subnet. In this case, the client device is sending DHCP discovers with a source IP address of 169.254.x.x instead of the expected 0.0.0.0.

A client should not be sourcing the DHCP discover using the APIPA address, as that goes against the standard set forth in RFC 2131:

"DHCP messages broadcast by a client prior to that client obtaining its IP address must have the source address field in the IP header set to 0."

So it is an expected behavior ! I will have to investigate why our HVAC windows machines are suddenly doing that.

[StevePF]

Hi Raphael,
Looks  like I am running to the same issue but with some alarm controllers.  The source IP 169.254 is also used and the packets are dropped (unfortunately, not many logs on this). 

Did you find a work around?

Thanks,

Steve

[RaphaelL]

There are 4 ways to 'solve' this issue.

1- Contact your vendor and let them fix the DHCP issues ( Will take forever ) 

2- Update the firmware , OS of that alarm controller ( if this is a known issue on their side, it might be already fixed )

3- Set the device in IP static ( not ideal )

4- Disable IP Spoofing ( not ideal either ) 

We ending up rebooting and factory reset our defective machines and it is now working fine.

[StevePF]

Thanks, 

Steve