Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

two DHCP reservations messing up client gateway and DHCP options

I noticed a strange mixing of DHCP settings when having 2 reservations for one client MAC address.

console> system dhcp static-entry-scope show
global

I have a VLAN on the XGS lets say VLAN10 Net: 10.1.2.0/24 GW: 10.1.2.1

On that VLAN is a XGS DHCP Server with some specific DHCP options for that VLAN10 with a reservation for dummy client aa:aa:aa:aa:aa:aa -> 10.1.2.20

On that XGS there is a RED20 with IP of 192.168.1.1/24 GW 192.168.1.1

On that RED is a XGS DHCP Server with a reservation for the same dummy client: aa:aa:aa:aa:aa:aa -> 192.168.1.20

Intension is: when the client moves, it should get a specific IP on the RED and a specific IP on the VLAN.

Now in real life, when the client is on the RED network, it gets the IP 192.168.1.20 from the RED DHCP Server, but all other DHCP options come from the VLAN DHCP Server: gateway 10.1.2.1 and all the DHCP options from the VLAN.

is that normal?

I had to delete the reservation on the VLAN DHCP server to make the client be served the correct IP settings from the RED DHCP Server.

all on SFOS 20.0.1



Added v20.0 MR1 TAG
[edited by: Erick Jan at 11:48 PM (GMT -7) on 27 Jun 2024]
Parents
  • Hi,

    I suspect the use of the RED is the cause of the issue? I have used that setting in the past without any issues like you described but only on local networks.

    Ian

    XG115W - v20.0.1 MR-1 - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • I was thinking in the same direction  that due to the RED XGS behaves different as on VLAN Interfaces.

    I noticed the issue because the client on the RED remained offline in our monitoring. When tcpdumping on redsXX interface I could see it was ARPing all the time to find the wrong gateway 10.1.2.1 and was isolated in that network without any gateway.

    When DHCP request was sent, the DHCP offer came from the firewall IP in the VLAN 10.1.2.1  and was broadcasted on the redsXX interface. I'm quite sure, this is not intended.

    The good thing was, it's a Linux OS and I could SSH to it from the firewall CLI and do some debug and check network settings on the client.

    tcpdump -i reds36 port 67 or port 68 -nvv
     
     0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:aa:aa:aa:aa:aa, length 300, xid 0xa442bd6a, Flags [none] (0x0000)
      Client-Ethernet-Address aa:aa:aa:aa:aa:aa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Client-ID Option 61, length 7: ether aa:aa:aa:aa:aa:aa
        Requested-IP Option 50, length 4: 192.168.1.20
        MSZ Option 57, length 2: 576
        Parameter-Request Option 55, length 8: 
          Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
          Domain-Name, BR, NTP, Vendor-Option
        Vendor-Class Option 60, length 4: "xxxx"
    19:44:48.157318 reds36, OUT: IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 333)
        10.1.2.1.67 > 192.168.1.20.68: [udp sum ok] BOOTP/DHCP, Reply, length 305, xid 0xa442bd6a, Flags [none] (0x0000)
      Your-IP 192.168.1.20
      Client-Ethernet-Address aa:aa:aa:aa:aa:aa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 10.1.2.1
        Lease-Time Option 51, length 4: 1295920
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 10.1.2.1
        Domain-Name-Server Option 6, length 4: 10.1.2.1
        Domain-Name Option 15, length 19: "internal-domain.com"
        NTP Option 42, length 8: 172.16.2.235,172.16.2.245
    19:44:48.257118 reds36, IN: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
        0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:aa:aa:aa:aa:aa, length 300, xid 0xa442bd6a, Flags [none] (0x0000)
      Client-Ethernet-Address aa:aa:aa:aa:aa:aa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Request
        Client-ID Option 61, length 7: ether aa:aa:aa:aa:aa:aa
        Requested-IP Option 50, length 4: 192.168.1.20
        Server-ID Option 54, length 4: 10.1.2.1
        MSZ Option 57, length 2: 576
        Parameter-Request Option 55, length 8: 
          Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
          Domain-Name, BR, NTP, Vendor-Option
        Vendor-Class Option 60, length 4: "xxxx"
    19:44:48.257243 reds36, OUT: IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 333)
        10.1.2.1.67 > 192.168.1.20.68: [udp sum ok] BOOTP/DHCP, Reply, length 305, xid 0xa442bd6a, Flags [none] (0x0000)
      Your-IP 192.168.1.20
      Client-Ethernet-Address aa:aa:aa:aa:aa:aa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 10.1.2.1
        Lease-Time Option 51, length 4: 1295920
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 10.1.2.1
        Domain-Name-Server Option 6, length 4: 10.1.2.1
        Domain-Name Option 15, length 19: "internal-domain.com"
        NTP Option 42, length 8: 172.16.2.235,172.16.2.245

  • first was a DHCP renew,  here is a fresh discover

    tcpdump -i reds36 port 67 or port 68 -nvv
    
    
    19:38:46.320223 reds36, IN: IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
        0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from aa:aa:aa:aa:aa:aa, length 300, xid 0x3b494f57, Flags [none] (0x0000)
      Client-Ethernet-Address aa:aa:aa:aa:aa:aa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Discover
        Client-ID Option 61, length 7: ether aa:aa:aa:aa:aa:aa
        MSZ Option 57, length 2: 576
        Parameter-Request Option 55, length 8: 
          Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
          Domain-Name, BR, NTP, Vendor-Option
        Vendor-Class Option 60, length 12: "udhcp 1.25.1"
    19:38:46.320349 reds36, OUT: IP (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 333)
        10.1.2.1.67 > 192.168.1.20.68: [udp sum ok] BOOTP/DHCP, Reply, length 305, xid 0x3b494f57, Flags [none] (0x0000)
      Your-IP 192.168.1.20
      Client-Ethernet-Address aa:aa:aa:aa:aa:aa
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: Offer
        Server-ID Option 54, length 4: 10.1.2.1
        Lease-Time Option 51, length 4: 1290304
        Subnet-Mask Option 1, length 4: 255.255.255.0
        Default-Gateway Option 3, length 4: 10.1.2.1
        Domain-Name-Server Option 6, length 4: 10.1.2.1
        Domain-Name Option 15, length 19: "internal-domain.com"
        NTP Option 42, length 8: 172.16.2.235,172.16.2.245

  • Hello LHerzog,

    Looking the tcpdump (Discover and Offer), it doesn't look like RED interface specific issue.

    Also, this shouldn't be recent issue as there are no major changes went in v20-MR1 in DHCP server side.

    Could you please confirm whether you have observed similar problem in previous version as well?

    Let us try to understand problem from our side and if required, will connect with you for device access.

    Regards,

    Sanket Shah

    Director, Software Development, Sophos Firewall

  • Hi  If a MAC address is statically binded in more than one DHCP server, then sometimes the client could get incorrect configuration information(eg: DNS, gateway, etc). In the past 5-6 years back, such issues were reported during V17.x firmware and as a solution to this problem DHCP conf generation method "new" was introduced around that time (long back around V17.5 firmware time) and changing to it would solve the problem.

    Can you please confirm this particular firewall which DHCP conf generation method is set to it?

    console> sy dhcp conf-generation-method show

    If it is set to old then you may set it to new to prevent the issue reported in this thread.

    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 'Verify Answer' link.

  • thanks, that's a good point. I have seen that in some release notes, found it was legacy on our firewall - and ignored it. Our firewalls origin is v16 or v17.

    confirmed: it's set to "old"

Reply Children