SOLUTION: 11.1R2.3 breaks dhcp server and client

[cryptochrome]

---

WL wrote:
Hi folks Sorry my mistake, the issue also exists from 11.2R1 onwards. The short-term workaround is that if you have DHCP client configured, ip spoofing should not be configured on the zone that the interface resides in. This is due to a change we had in behavior which is checked in from 11.1R2 11.3R1 11.2R1 The rationale behind this is that during the detection of ip spoofing, route lookup has to be done for the source address. After route lookup has been done it will compare the input interfaces with the result of the route lookup. In the case for DHCP clients, since it picks up the default route as discard and drops the packet as spoofed packet. In previous releases, if 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 are still in discussion for this issue at the moment as we understand that an exception has to be made for dhcp, will update more when more info is available.

---

WL, does this bug also affect the DHCP server part of the SRX (e.g. SRX serving IP addresses to clients) or only the DHCP client part?

We currently have an issue with two SRX DHCP servers (11.1) not working, so I am wondering if this might be related.

Thanks

[WL]

It may affect DHCP sever portion as well depending on what routes are configured on the SRX. The best way to confirm is actually to log the alerts from the screens.

set system syslog file screen any any

set system syslog file screen match SCREEN

Or you can also check if the screens have been triggered via:

show security screen statistics zone | match spoof

and check if counters increment when dhcp clients request IP address.

[cryptochrome]

just checked the screen statistics. Ip spoofing has zero hits.

[WL]

yea then you have a different problem. did you try to turn on the dhcp traceoptions to take a look? set system services dhcp traceoptions flag all set system services dhcp traceoptions file

[cryptochrome]

---

WL wrote:
yea then you have a different problem. did you try to turn on the dhcp traceoptions to take a look? set system services dhcp traceoptions flag all set system services dhcp traceoptions file

---

yeah, we tried that already. In fact, we have a JTAC case open and they asked us to disable IP spoofing after I pointed them to this thread here :-)

Anyways, since this seems to be a different issue, I will take it elsewhere. Don't want to hijack this thread.

Cheers

Sascha

[techniq]

I actually already tried a stateless firewall filter based UDP port 67 or 68 (can't remember)...in any case it did not work.  I assume because the spoofing screen inspects stateful and stateless traffic, which would make sense.

[cryptochrome]

---

cryptochrome wrote:

---

WL wrote:
yea then you have a different problem. did you try to turn on the dhcp traceoptions to take a look? set system services dhcp traceoptions flag all set system services dhcp traceoptions file

---

yeah, we tried that already. In fact, we have a JTAC case open and they asked us to disable IP spoofing after I pointed them to this thread here :-)

Anyways, since this seems to be a different issue, I will take it elsewhere. Don't want to hijack this thread.

Cheers

Sascha

---

I might add: We just disabled IP spoofing and now the DHCP server is working. So even though there were no hits on the IP spoofing counter, it broke DHCP server.

[cryptochrome]

So when and in which version will we see a fix?

[AidanOS]

It's dissapointing to hear that for every 11.x release this year the problem has existed and that the only workaround is to disable the spoof protection or custom configure a stateless filter.  Would it be possible to create a separate spoofing filter that allowed broadcasts?

[WL]

Actually I am not quite sure if my previous post explained it clearly.

The reason why DHCP worked earlier is because ip spoofing was not working correctly! In the past ip spoofing was actually not comparing the input and output interfaces when addresses matched the default route!

So we fixed this behaviour and as a result its affecting the DHCP traffic now.

IMHO, I dont think we need spoofing check for DHCP packets on interfaces that require DHCP since DHCP is required for the interface.

Thats why I thought my previous post  to use the firewall filter with packet based processing specifically for DHCP packets is a better solution then deactivating spoofing altogether, has anyone tried it?

Only thing I want to add to it is that you may want to explicitly define the dest ports and protocol to be sure that the filter is only matching dhcp packet.