This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

DHCP Requests to XG blocked by Local_ACL

Hi,

today we faced massive network problems after adding an other DHCP Relay on XG. Basic task, already have a few dozends running.
A lot of clients could not get DHCP addresses from their relay anymore (existing relays).

After recreating one random relay, all issues with the DHCP requests over the relays seem to have gone. So this is the first strange issue but only the story to the following problem:

We have DHCP servers on the XG as well. And I notice lots of blocked requests / INVALID due to Local_ACL as seen below:

Packet Capture lists this:

Time

In interface

Out interface

Ethernet type

Source IP

Destination IP

Packet type

Ports [src,dst]

NAT ID

Rule ID

Status

Reason

Connection ID

2020-12-02 11:35:23

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Incoming  

0

2020-12-02 11:35:22

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Violation

Local_ACL

1421341696

2020-12-02 11:35:22

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Incoming  

0

2020-12-02 11:35:21

lag0.57

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Violation

Local_ACL

3276029440

2020-12-02 11:35:21

lag0.57

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Incoming  

0

2020-12-02 11:35:19

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Violation

Local_ACL

3799521216

2020-12-02 11:35:19

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Incoming  

0

2020-12-02 11:35:19

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Violation

Local_ACL

3799521216

2020-12-02 11:35:19

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Incoming  

0

2020-12-02 11:35:16

reds24.1340

  IPv4 0.0.0.0 255.255.255.255 UDP 68,67

0

0

Violation

Local_ACL

179216704

And this is the tcp dump to those packets:

11:35:16.900009 reds24.1340, IN: IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:0d:b0 (oui Unknown), length 300
11:35:19.935962 reds24, IN: ethertype IPv4, IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:06:44 (oui Unknown), length 300
11:35:19.935962 reds24.1340, IN: IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:06:44 (oui Unknown), length 300
11:35:19.960002 reds24, IN: ethertype IPv4, IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:0d:b0 (oui Unknown), length 300
11:35:19.960002 reds24.1340, IN: IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:0d:b0 (oui Unknown), length 300
11:35:21.411297 PortA4, IN: ethertype IPv4, IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 78:ac:c0:8f:e3:04 (oui Unknown), length 300
11:35:21.411297 lag0, IN: ethertype IPv4, IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 78:ac:c0:8f:e3:04 (oui Unknown), length 300
11:35:21.411297 lag0.57, IN: IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 78:ac:c0:8f:e3:04 (oui Unknown), length 300
11:35:21.411340 lag0, OUT: IP XG-FIREWALL-IP.bootps > DHCPSERVER.local.domain.bootps: BOOTP/DHCP, Request from 78:ac:c0:8f:e3:04 (oui Unknown), length 300
11:35:21.411342 PortA2, OUT: IP XG-FIREWALL-IP.bootps > DHCPSERVER.local.domain.bootps: BOOTP/DHCP, Request from 78:ac:c0:8f:e3:04 (oui Unknown), length 300
11:35:22.995976 reds24, IN: ethertype IPv4, IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:06:44 (oui Unknown), length 300
11:35:22.995976 reds24.1340, IN: IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:06:44 (oui Unknown), length 300
11:35:23.020034 reds24, IN: ethertype IPv4, IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from 7c:5a:1c:05:0d:b0 (oui Unknown), length 300

How can I find the root cause of the Violation?



Edited context due to Privacy request by user
[edited by: emmosophos at 9:18 PM (GMT -7) on 4 May 2021]
Parents
  • I saw this issue once by a customer, using dozens of reds in a DHCP Relay and there were couple REDs offline for other reasons. Those defect REDs killed the whole relay. After finding and removing those reds from DHCP Relay, everything was up and running.

    Would recommend to look for Offline REDs. 

    __________________________________________________________________________________________________________________

Reply
  • I saw this issue once by a customer, using dozens of reds in a DHCP Relay and there were couple REDs offline for other reasons. Those defect REDs killed the whole relay. After finding and removing those reds from DHCP Relay, everything was up and running.

    Would recommend to look for Offline REDs. 

    __________________________________________________________________________________________________________________

Children
  • There are in fact some REDs offline but I'm not sure how to handle your suggestion. I cannot delete them just for a test.

    Those offline REDs are usually from people that are working in the company today and have turned off their homeoffice IT.

    what I find strange is that the devices belonging to the MAC addresses above already have an IP address.

    7c:5a:1c:05:0d:b0 is an APX320 managed by Central

    7c:5a:1c:05:06:44 is also APX320 managed by Central

    They get the IP from XG on the RED interface.

    Those devices appear every 1 or 2 seconds with those violations

    But I monitored those events also for other VLANs that are DHCP relayed over the XG and those LANs are internal VLANs.

    One examle is VLAN lag0.57 shown in the lists above and I have monitored at least 2 others in the GUI packet capture.

    update: I created a support case for this: 03403509