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

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 11 replies
  • Subscribers 42 subscribers
  • Views 3194 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

two DHCP reservations messing up client gateway and DHCP options

LHerzog

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



This thread was automatically locked due to age.
Parents
  • 0

    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.2 MR-2 - Home

    XG on VM 8 - v21 GA

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

  • 0 in reply to rfcat_vk

    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

  • 0 in reply to LHerzog

    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

  • 0 in reply to LHerzog

    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

  • +1 in reply to LHerzog

    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.

  • 0 in reply to Vishal_R

    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"

  • 0 in reply to LHerzog

    Thanks for the quick confirmation and validation on this , I believe setting up it to new will fix this issue for you on this firewall.

    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.

  • +1 in reply to Vishal_R

    just as you did , the documentation describes the exact issue and that the "new" setting fixes it.

    conf-generation-method [new | old] [show]

    Method of generating the backend DHCP configuration file.

    You require the new file format if you've bound a MAC address in more than one DHCP server configuration. The old method may provide incorrect information, such as for DNS servers and gateway.

    Default: old
  • 0 in reply to LHerzog

    I'd change that after working hours but are there known issues to look at after changing the setting?

Reply Children
Unfiltered HTML