Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 8 replies
  • Subscribers 39 subscribers
  • Views 2113 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

Home XG MR18 new install DHCP Relay not working

FillDee

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.



This thread was automatically locked due to age.
Parents Reply Children
  • 0 in reply to FormerMember

    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

  • 0 in reply to AlexanderPoettinger

    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.

Unfiltered HTML