SRX as DHCP client or DHCP relay/server does not work on Junos 11.1R2 and later releases when IP spoofing is configured

This article describes the issue of SRX as DHCP client or DHCP relay/ server not working on Junos 11.1R2 and later releases, when IP spoofing is configured.

There are three scenarios where IP spoofing is configured on the zone for the SRX device, but the SRX device does not function correctly as either a DHCP relay/ server or a DHCP client on 11.1R2 release and above releases.

In the case of the SRX as the DHCP client, it is unable to obtain an IP address as the DHCP offer messages are dropped due to the IP spoofing screen. In the case of the SRX as the DHCP Relay/ Server, it is unable to receive DHCP discover messages as these messages are also dropped due to the IP spoofing screen.

Sample configuration for the SRX as DHCP client with IP Spoofing screen:

Interface:

Zone:

Screen:

How to verify whether the DHCP packets are being detected as spoofed packets:

1.Check the screen statistics to see if screen counters are incrementing when requesting an IP address:

2.Log the spoof messages to check whether the packet which triggered the spoof is actually the DHCP packet:

A sample output for the screen triggered by DHCP offer packet should look like the following:

A sample output for the screen triggered by DHCP discover message should look like the following:

This is due to a change in behavior which is checked from Junos 11.1R2 ,11.3R1, and 11.2R1.

A quick explanation of how IP spoofing functions is that in IP spoofing, the route lookup will be done for the source IP address of an incoming packet to determine from which interface the packet should have reached the device. The screen module then compares the actual ingress interface of the packet with the result from the route lookup.

In the case of DHCP clients, since it picks up the default route as a discard, the packet is dropped as a spoofed packet. In previous releases, if the default route is matched, we allow the traffic to pass without matching the input interface. So, the spoofing check was incorrect in older releases.

We will be changing the behaviour so that DHCP packets will be allowed to pass when configured with spoofing on the interface. The versions which resolve this issue are: 11.1R7, 11.2R5, 11.3R4, 11.4R2.

There is also another workaround for this issue if an upgrade is not possible:

  • Use selective packet based forwarding by pass flow processing for DHCP packets.

An example for the second workaround is as follows:

Interface:

Zone:

Screen:

Firewall filter:

Result:

In this case, the interface will be able to get DHCP IP:

 

About the author

Prasanna

Leave a Comment