Static DHCP assignments broken with multi-boot client?

I think this might be a bug, but not sure where the best place to ask/report it is.

I assigned a static IP address to my primary Linux workstation (10.144.1.10/ac:ef:1b:66:23:1a), everything works as expected. I reboot the PC into Windows 10, again as expected I get my static assignment and everything works. When I reboot from Windows back into Linux the firewall refuses to assign me an IP. When I sniff I see a DHCP REQ and immediately a DHCP NAK from the XG. If I delete the static assignment on the firewall I then get a random address from the pool. If I then re-add the static address everything works again until I boot Windows 10.

Thoughts?

  • Hi,

    Greetings.

    Try upgrading to SF-OS MR 1.1 :)

    Thanks

    Sachin Gurung

  • In reply to sachingurung:

    Still broken. Replicated on 3 computers. Only occurs when there is a static entry. Dual-boot Win/Linux is fine if getting a truly dynamic address. Easy to replicate.

    Take dual boot computer, assign a static address in the DHCP server on XG. Boot Windows, then Linux. Linux will not get an IP.

  • In reply to chetwisniewski:

    Hi,

    Greetings.

    I request you to report this instance to our Support Team, you can reach them through mail on support@sophos.com, so that they can report this to the concerned team to check if that is a related BUG.

    Thanks

    Sachin Gurung

  • In reply to sachingurung:

    still isn´t working - ver (SFOS 17.0.5 MR-5)

     

    It is very inconvenient for us.

    With regards

  • In reply to Jiri Hadamek:

    Hi,

    this might seem like a dumb question, do you restart or power off and on?

    Ian

  • In reply to rfcat_vk:

    I cannot say that I understand your question.

    After every firmware upgrade we rebooted. And problem exhibited itself AFTER reboot from Windows to Linux.

    We have this problem more than two years - dual boot machine LIN/WIN. This problem is easily reproducible from ver 15.X firmware.

     

    We found only one very clumsy workaround.

    - Remove MAC from static DHCP list and save (in XG network configuration)

    - Reboot workstation - it get address from dynamic pool

    - Add static MAC into list again adn save

    - Reboot workstation - it gets correct address.

    If we had reboot workstation again into "second - different" system - it doesn´t get address from DHCP server. If we rebooted to "previous" system, it get address correctly.

     

    I hope this help to understand our (and not only our) problem.

     

     

     

  • In reply to Jiri Hadamek:

    What I am asking is if you actually turn the power off before changing between operating systems? The XG DHCP server will more than likely still an active lease because the lease will not have expired and from memory Windows and LINUX do address requests differently.

    Ian

  • In reply to rfcat_vk:

    Hi,

    we looked into this problem several times.

    And  - yes - the problem is the same if we did cold shutdown and start or simply restarted.

    We sniffed for LAN packets with Wireshark and found this: If "another system" want IP address via "DHCP REQUEST" packet, it didn´t get ANY answer from Sophos XG if their Ethernet MAC  is assigned already in DHCP Sophos XG table.

     

  • In reply to Jiri Hadamek:

    Sadly this appears to be intentional. I would escalate it as a bug/feature request. There is a workaround:

    To overcome from the issue, you can enable below feature through  CLI
    
    Command :  console> system dhcp one-lease-per-client enable
  • In reply to chetwisniewski:

    I think, that some misunderstanding persisted.

    I cannot believe that it is intentional. If I try several times get IP address from DHCP server, i GOT IT (restart, shutdown and start, ifconfig /renew etc. etc.).

    If I start different system ON THE SAME HARDWARE or with the SAME MAC address on THE SAME LAN CABLE, then i won´t get answer from DHCP server if my MAC address is in lease table on Sophos firewall.

    We catched all network traffic and we cannot se any major difference in LAN packets to DHCP server.