Thread Info
  • State Verified Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 18 replies
  • Answers 3 answers
  • Subscribers 37 subscribers
  • Views 33878 views
  • Users 0 members are here
Options
Suggested
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 Relay Not working

PowerOverwhelming

Hi. I have a XG330 setup to do routing for my Guest network 172.16.100.0/24. I have a relay pointing to my DHCP server however my clients aren't getting any ip addresses. The firewall is plugged into a HP switch and its a trunk port. the vlans are tagged.  If i let the switch do the routing the clients get ip addresses but it doesnt look like the firewall relay is working.

the guest network is setup as a subinterface on the xg330. any ideas?

thanks



This thread was automatically locked due to age.
  • 0 in reply to Ste

    I have the same problem.. Whenever I turn off the XG and relay, I need to apply the ralay configuration of a VLAN at least to start working.

  • 0 in reply to sachingurung

    Hello,

    How would this static route be?

  • +2

    I ran into this same issue (getting "Appliance Access" denied on DHCP requests), and this may not be the fix for everyone else, but I spun my wheels on it for hours and finally figured it out. But I seen many questions of this with no answers so I wanted to make sure I shared my findings. 

    I had a DHCP relay set for the same subnet as my actual Windows DHCP server. In my head, I wanted one set for every subnet, but for one, you dont need it in the same subnet anyway. Two, any request sent to that subnet will get looped and Sophos wont know what to do with it. As soon as I deleted the relay that was in the same subnet as the DHCP server, it was fixed. 

    Just for test, I added it back, and could not get a DHCP address anymore. As soon as I removed it again, it worked.

    Hope this helps someone else!

    EDIT: In case it helps, I explained this in a little more detail in a blog post I made.. https://moreabout.tech/sophos-xg-firewall-windows-dhcp-server-not-getting-ip-addresses/

  • 0 in reply to Alex Riggs

    Hah! That was the issue for me as well. I didn't think it through and once I read your post it made perfect sense. [Y]

  • 0 in reply to Randal Johnson

    Hi  and  - Just for my information, what exactly did you fix? 
    Reporting Issues (such as dropped packets in the Logging by Local ACL), or couldnt other VLANs receive any IPs? 

     

     

    I read the post on your website but your Conclusion seems not be correct, as far as i could reproduce this.

    Someone may have a better understanding of it and can explain better in the comments, but what my assumption is, when the DHCP request goes out, it gets blasted to the entire vlan to find a DHCP server by blasting out to port 67/68 UDP in search of a DHCP server. The gateway at 192.168.2.1 forwards this to the 192.168.1.0/24 vlan and it receives the blast on that subnet for the response, and blasts that back out to the requesting vlan.

    If you put in a DHCP relay on the same subet as the DHCP server, then when it tries to “blast” the response back, the gateway takes that requests and tries to re-blast it in the same subnet. This causes a malformed loop and causes the request to fail. Thus removing the DHCP relay on the VLAN the DHCP server is in should fix this.

    Please let me know if you have a better understanding of the cause or if this helps you!

     

    XG uses a Broadcast to Unicast Relay Agent Technique. So you convert the Broadcast Packet to a unicast packet and sends this directly to your DHCP Server.

     

    It looks like:

    16:13:26.759272 reds1, IN: ethertype IPv4, IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:5a:1c:78:87:3f, length 280
    16:13:26.759272 reds1.10, IN: IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 7c:5a:1c:78:87:3f, length 280
    16:13:26.759406 reds1.52, OUT: IP 192.168.52.1.67 > 192.168.52.50.67: BOOTP/DHCP, Request from 7c:5a:1c:78:87:3f, length 280

     

    So incoming on 0.0.0.0 to 255.255.255.255, XG transform this to a Unicast and sends it directly to your configured DHCP Server. 

     

    If you open such a Packet, you will find, that XG leaves the same packet but put the Relay Agent IP into it.

     

    This is kinda normal. That helps the DHCP verify, which scope he has to use.

     

    I did some more research on this and could not reproduce this issue at all. So even with a DHCP relay in the VLAN of the DHCP server, the server was still be reachable by all Clients. 

    Maybe i have to put more time into it. 

  • 0 in reply to LuCar Toni

    Here's my DHCP relay configuration from our XG, as an example:

     

    Name Port.VLAN XG IP Network DHCP Servers
    VoIP A1.1012 10.1.2.254 10.1.2.0/24 10.1.1.1, 10.1.1.2
    WiFi A1.1013 10.1.3.254 10.1.3.0/24 10.1.1.1, 10.1.1.2
    Data A1.1014 10.1.4.254 10.1.4.0/24 10.1.1.1, 10.1.1.2
    AudioVisual A1.1015 10.1.5.254 10.1.5.0/24 10.1.1.1, 10.1.1.2
    Guest WiFi A1.1016 10.1.6.254 10.1.6.0/24 10.1.1.1, 10.1.1.2

     

    This works as expected. However, when I was having issues, my DHCP relay configuration looked like this:

    Name Port.VLAN XG IP Network DHCP Servers
    Rack A2.1011 10.1.1.254 10.1.1.0/24 10.1.1.1, 10.1.1.2
    VoIP A1.1012 10.1.2.254 10.1.2.0/24 10.1.1.1, 10.1.1.2
    WiFi A1.1013 10.1.3.254 10.1.3.0/24 10.1.1.1, 10.1.1.2
    Data A1.1014 10.1.4.254 10.1.4.0/24 10.1.1.1, 10.1.1.2
    AudioVisual A1.1015 10.1.5.254 10.1.5.0/24 10.1.1.1, 10.1.1.2
    Guest WiFi A1.1016 10.1.6.254 10.1.6.0/24 10.1.1.1, 10.1.1.2

    As you can see I have a DHCP relay configured that exists for the same VLAN/Subnet that the DHCP server resides on.

    So here is an example of what I believe was happening:

    1) Plug a device into an open port on a switch with a primary VLAN of 1014.

    2) The device broadcasts a DHCP request, the switch tags it with the appropriate VLAN tag and forwards it out the trunk port to the XG.

    3) The XG receives the DHCP request on interface A1.1014

    4) The XG consults the DHCP relay table, and sees that DHCP requests on the interface A1.1014 should be relayed to 10.1.1.1 and/or 10.1.1.2

    5) However, 10.1.1.1 belongs to subnet 10.1.1.0/24 on interface A2.1011 which is also configured with a DHCP relay. So the DHCP request should instead be relayed to the server(s) for interface A2.1011.

    6) The XG consults the DHCP relay table, and sees that DHCP requests on the interface A2.1011 should be relayed to 10.1.1.1 and/or 10.1.1.2

    7) However, 10.1.1.1 belongs to subnet 10.1.10/24 on interface A2.1011 which is also configured as a DHCP relay. So the DHCP request should instead be relayed to the server(s) for interface A2.1011.

    8) The XG consults the DHCP relay table.....

     

    And so on, and so on.

     

    I think it would probably be a good idea for the firmware to prevent DHCP relays from being added where the destination DHCP server exists on the same subnet as the interface.

  • 0 in reply to Randal Johnson

    Did some more research about this.

     

    Simple setup (as i cannot use VLAN right now).

     

     

    Relay:

     

     

     

     

     

    Client behind PortC. Relay through XG. 

    14:43:47.066047 PortC, IN: IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:d6:eb:a1, length 331
    14:43:47.066359 PortA, OUT: IP 192.168.100.10.67 > 192.168.100.50.67: BOOTP/DHCP, Request from 00:0c:29:d6:eb:a1, length 331
    14:43:47.068326 PortA, IN: IP 192.168.100.50.67 > 192.168.10.10.67: BOOTP/DHCP, Reply, length 301
    14:43:47.079812 PortC, OUT: IP 192.168.10.10.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

     

    Client in PortA (Same Network as the DHCP server).

    14:34:56.906296 PortA, IN: IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:ae:ed:4a, length 300
    14:34:56.906297 PortA, IN: IP 192.168.100.50.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
    14:34:56.906875 PortA, OUT: IP 192.168.100.10.67 > 192.168.100.50.67: BOOTP/DHCP, Request from 00:0c:29:ae:ed:4a, length 300
    14:34:56.915716 PortA, IN: IP 192.168.100.50.67 > 192.168.100.10.67: BOOTP/DHCP, Reply, length 300
    14:35:27.422501 PortA, IN: IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:0c:29:ae:ed:4a, length 300
    14:35:27.422691 PortA, OUT: IP 192.168.100.10.67 > 192.168.100.50.67: BOOTP/DHCP, Request from 00:0c:29:ae:ed:4a, length 300
    14:35:27.433844 PortA, IN: IP 192.168.100.50.67 > 192.168.100.10.67: BOOTP/DHCP, Reply, length 300
    14:35:27.434024 PortA, IN: IP 192.168.100.50.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300

     

    As you can see, the client gets the answer by the DHCP server and XG. 

     

     

     

    If you can reproduce this issue with VLAN, maybe you could create the same tcpdumps? 

    tcpdump -ni any port 67 or port 68

     

     

  • 0 in reply to LuCar Toni

    xg 17.5.13 -  Got a similar issue.  Everything worked well until I had to trunk 2 VLAN on the same interface with a relay each 

    PortE4.50    relay in place for years, no problem

    create PortE4.60   relay do not work, dhcp traffic is dropped.

     

    This is the first time I run into that issue as I never had 2 relays on the same trunk in the past. it is EXTREMELY annoying.

     

    I'll try to get a TCP dump later, right now I need to find a workaround.