Home XG MR18 new install DHCP Relay not working

So, I've been using the home version of UTM for many, many years. All has been good, but now I'm hitting the IP limit (Thanks IoT!).

So I've installed XG alongside the original UTM VM with an interface on my main network, a private link from the XG WAN port to an input in the UTM, and a separate Port connected to a VLAN.

Pointing a PC to the XG as the router, works absolutely fine. Even on the VLAN interface, it works great. But... ONLY if it has a static IP. When I try to use the DHCP relay function on the XG, I get an error in the pCAP as shown below. This shows port 68,67 status viaolation, reason Local_ACL

I've added the DHCP relay to the VLAN port and pointed to the DHCP server. I also tried adding various Any<>Any rules in the firewall config and tried (without success) to add a DHCP application to the Device Access (can't seem to find a way to add DHCP to this).

As an aside, if I enable an XG DHCP server on this same VLAN port, I get an IP address, so all my VLAN tagging and network access outside the XG is fine.

With the UTM, it was so much simpler....and it worked fine...

Any idea what I am missing?

Thanks in advance.

  • Hi  

    Packet capture may show violation for DHCP and DHCP relay traffic:

    https://community.sophos.com/kb/en-us/134616

    TCPDUMP, PCAP will be more helpful to identify and fix the issue if you are facing an issue with DHCP relay:

    TCPDUMP command:

    console> tcpdump 'port 67 or 68 -Aa

    PCAP KBA:

    https://community.sophos.com/kb/en-us/127647

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link.

  • Thanks for the article, it did help a bit. 

    Running a console packet capture and analysing it, shows this that it does seem to create the DHCP requests.

    I don't see anything in the DHCP server logs, so not sure the requests are reaching the DHCP server.

    As I said, the same setup with the same DHCP server works absolutely fine with UTM, so not really sure where to go from here.....

  • I've marked the answer as correct, since it led me down the correct path.

    Turned out the DHCP requests and offers were being received / given, but the DHCP Server didn't know how to get back to the remote network.

    My fault :)

    Thanks

  • Hi  

    Thanks for sharing the resolution and I am glad to hear you managed to fix the issue.

    Regards,

    Vishal Ranpariya
    Technical Account Manager | Sophos Technical Support

    Sophos Support Videos | Knowledge Base  |  @SophosSupport | Sign up for SMS Alerts |
    If a post solves your question use the 'This helped me' link.

  • HI, I've got the same problem. 

    The firewall is an XG 135 on SFOS 18.0.1

    Difference is, that my DHCP servers are behind a routing based IPsec.

    I set-up the DHCP Relay pointing to the DHCP servers.

    The firewall can talk correctly to the DHCP servers behind the IPsec VPN as these are also the domain controllers for authentication and the autentication against the same servers works fine.
    Therefore there is no routing problem here.

    Still regardless whether I activate the "relay through IPsec" option for the DHCP relay or not, regardles of any firewall rule, I'm still getting the ACL violation and the packets are not forwarded through the IPsec.

    What am I missing?

    Alexander Poettinger

    Sophos Certified Architect - XG
    Sophos Certified Technician - XG
    Sophos Certified Engineer - UTM

    xame gmbh
    Sophos Gold Partner

  • Hi ,

    Did you configure system routes required to route system-generated traffic over the IPsec tunnel? 

    Check out the following KBA for more detail: Sophos XG Firewall: How to Route Sophos Firewall Initiated Traffic Through an IPSec VPN tunnel

    Note: The configuration in the KBA should also work when you set a DHCP Relay over IPsec, you just need to configure the firewall as a DHCP Relay.

    I would also suggest you check if the DHCP service is running under > System services > Services. 

    Thanks,

     

     
    H_Patel

    Community Support Engineer, Support & Services | Sophos Technical Support
    Support Videos | Product Documentation | @SophosSupport | Sign up for SMS Alerts
    If a post solves your question use the 'Verify Answer' button.

  • Good morning, as I described in my post, this is a routing-based IPsec, not a policy-based one.
    There are fixed routings for the network connections.
    Also in my description is the information that system-generated traffic is capable of going through the IPsec because authentication traffic from the firewall to the Active Directory server (which is also the DHCP server) over the same IPsec is working properly.

    The console commands in the KB you posted is well known to me and only works with policy-based IPsec connections.
    I tried executing the command but - as expected - since the IPsec is routing-based the command does not recognise the name of the IPsec connection.

    The DHCP service as such is running, because the system is providing DHCP to the WiFi and once I configured the DHCP on the LAN connection it worked immediately.

    Alexander Poettinger

    Sophos Certified Architect - XG
    Sophos Certified Technician - XG
    Sophos Certified Engineer - UTM

    xame gmbh
    Sophos Gold Partner

  • Sounds definitely similar to my issue. I know you say you have no routing problems, but that's what I thought, as all traffic to the internet etc, was working fine. The firewall itself had no issues either, as that knew about the subnets. My direct problem, was that the DHCP server received a request from the DHCP relay (you can check that in the DHCP logs on the DHCP server - are the requests seen?), but it did not know how to get back to the remote subnet, so it sent the replies to it's gateway, which then sent them out of it's gateway, which was not the correct route back. Once I added the route back to the client subnet, to the DHCP servers gateway, then it all worked fine.

    Anyway, have a look in the DHCP logs. That will say if it's a "reply" issue, or a "request" issue and that might help you.