Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 3372 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

Curious DHCP behavior

SalishSwede
I'm moving a machine from one network to another and finding that the Astaro DHCP server sees that the machine is in different networks but it assigns it the same ip address no matter what network it's in.  This is not helpful.

[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPOFFER on 10.1.10.1 to 00:0c:29:bf:76:b7 (aardvark) via eth0 [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPOFFER on 172.16.1.10 to 00:0c:29:bf:76:b7 (aardvark) via eth3 [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPOFFER on 10.3.10.1 to 00:0c:29:bf:76:b7 (aardvark) via eth2 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: if aardvark.ravennasprings.com IN A rrset doesn't exist  add aardvark.ravennasprings.com 43200 IN A 10.1.10.1: timed out. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from 00:0c:29:bf:76:b7 (aardvark) via eth0 [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPACK on 10.1.10.1 to 00:0c:29:bf:76:b7 (aardvark) via eth0 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from  00:0c:29:bf:76:b7 (aardvark) via eth3: wrong network. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPNAK on 10.1.10.1 to 00:0c:29:bf:76:b7 via eth3 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from  00:0c:29:bf:76:b7 (aardvark) via eth2: wrong network. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPNAK on 10.1.10.1 to 00:0c:29:bf:76:b7 via eth2 [/FONT]
[FONT=monospace]2013:10:11-16:53:13  wahine dhcpd: DHCPREQUEST for 10.1.10.1 (10.1.1.2) from  00:0c:29:bf:76:b7 (aardvark) via eth4: wrong network. [/FONT]
[FONT=monospace]2013:10:11-16:53:13 wahine dhcpd: DHCPNAK on 10.1.10.1 to 00:0c:29:bf:76:b7 via eth4 [/FONT]


Can anyone think of a solution.  I don't want to manually change network addresses [that's what DHCP is for] and I'd rather not generate static entries for all my machines that travel.

Thoughts?

Thanks.


This thread was automatically locked due to age.
  • 0
    Firmware version:
    9.106-17 
     Pattern version:
    52011
  • 0
    Hi, how do you have the DHCP servers set up, and are these wireless (Sophos APs?) or wired networks?

    Barry
  • 0
    From the perspective of of Sophos, these are wired networks for running machines in isolation of each other (no vm's).  In reality they are interfaces connected to separate virtual nets on a VMWare ESXi hypervisor.

    Each network has its own DHCP server configured.
    It seems straight forward to me so I'm a bit surprised with these results.
  • 0
    OK.
    Can you post a screenshot of your ESXi virtual network?

    If you're using VLANs, I've seen it recommended to pass the vlan trunk from ESXi to the UTM and let it do all the VLANs itself, but it depends on your configuration.

    Barry
  • 0 in reply to BarryG
    I'm curious about this too.

    I have my Sophos virtualized and running multiple networks inside ESXi 5.

    It also worked not virtualized.  But, still DHCP for the multiple networks.  I am using VLANs though.
  • 0
    Not trying to hijack your thread, but I am having a somewhat similar issue.

    Sophos is running on a very simple ESXi VM at home, I have a single notebook that can not get on the correct subnet when it resumes from sleep.
    This same notebook has some serious connection throughput issues as well. I'd say it's this computer, however it did not have these issues before I put the Sophos UTM in place.

    2013:11:02-02:30:25 redrocker dhcpd: DHCPDISCOVER from 2c[:D]0:5a:79:1b:75 (hp-ENVY_m6) via eth0
    2013:11:02-02:30:25 redrocker dhcpd: DHCPREQUEST for 192.168.17.7 (192.168.17.1) from 2c[:D]0:5a:79:1b:75 via eth0: wrong network.
    2013:11:02-02:30:25 redrocker dhcpd: DHCPNAK on 192.168.17.7 to 2c[:D]0:5a:79:1b:75 via eth0
    2013:11:02-02:30:26 redrocker dhcpd: DHCPOFFER on 192.168.2.176 to 2c[:D]0:5a:79:1b:75 (hp-ENVY_m6) via eth0
    2013:11:02-02:31:12 redrocker dhcpd: DHCPREQUEST for 192.168.17.7 from 2c[:D]0:5a:79:1b:75 via eth0: wrong network.
    2013:11:02-02:31:12 redrocker dhcpd: DHCPNAK on 192.168.17.7 to 2c[:D]0:5a:79:1b:75 via eth0
    2013:11:02-02:31:26 redrocker dhcpd: DHCPREQUEST for 192.168.17.7 from 2c[:D]0:5a:79:1b:75 via eth0: wrong network.
    2013:11:02-02:31:26 redrocker dhcpd: DHCPNAK on 192.168.17.7 to 2c[:D]0:5a:79:1b:75 via eth0
    2013:11:02-02:31:31 redrocker dhcpd: DHCPREQUEST for 192.168.17.7 from 2c[:D]0:5a:79:1b:75 via eth0: wrong network.
    2013:11:02-02:31:31 redrocker dhcpd: DHCPNAK on 192.168.17.7 to 2c[:D]0:5a:79:1b:75 via eth0


    It should be getting x.x.2.100+.
    The only way to fix it is to fully reboot the machine, on a fresh start it's fine, but if it's put to sleep it resumes with this problem.

    I just updated Sophos to 9.004-33 earlier today, but the throughput issue and I believe this issue was present beforehand. Going to restore the pre-update snapshot and check.

    EDIT: No longer corrects itself on reboot. Not really sure what could be going on, as that subnet is not one which is assigned or issued anywhere in my UTM.
    Creating a static mapping does not correct the issue either. I feel strongly that this is an issue with this particular instance of Win 8, but not sure why it would have been working fine before Sophos went in place.
    If I assign the IPv4 info on the machine itself, all works fine (except it's still very slow).

    EDIT: It's definitely Sophos, as it has started handing this same address to android phones as well.
  • 0
    Hi, Derrick, and welcome to the User BB!

    EDIT: It's definitely Sophos, as it has started handing this same address to android phones as well.

    I don't see anything wrong in the log lines you showed us.  192.168.2.176 is the only IP offered by the UTM to 2c[:D]0:5a:79:1b:75.  All of the other lines are 2c[:D]0:5a:79:1b:75 asking for an IP that's not valid on eth0 and the UTM refusing.  If 192.168.2.176 is not associated to a MAC in the lease table, it can be assigned to another client.

    Cheers - Bob
  • 0 in reply to BAlfson
    Found the problem.

    There was a Sprint AirRave connected to the network via it's lan port instead of it's wan port.

    The AirRave has a built in DHCP server that hands out addresses in the 192.168.17.x range. 
    I switched the DHCP server from Sophos to a windows 2012 vm while trying to figure all of this out, and I'm a little surprised that windows didn't pick up on the co-existing server and disable itself, which would have instantly given me the indication that there was another one on the network.

    At any rate, everything seems to be chugging along fine now. Thank you for the assistance.
  • 0
    Hi,

    FWIW, You might want to tape-over the extraneous ports on such devices to avoid problems like that.

    Glad you figured it out.

    Barry