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

Unable to obtain DHCP lease through bridged VDSL modem

Hi there:

I could really use some suggestions.  Been running the home version of UTM 9 (Firmware version: 9.405-5) for a few months now with no issues.  My WAN connection on eth1 had been an ADSL using PPPoE, but this last weekend I finally got bumped up to a VDSL line using DHCP rather than PPPoE.  When I changed my WAN int to reflect this, I could not get a response to my DHCPDISCOVER packets.  The DSL modem I am using was placed in bridged mode, and when I use a laptop or a Cisco (Linksys) router configured for DHCP, I have no issues.  My troubleshooting so far is as follows:

  • Spoofing the MAC of the VDSL modem has no effect.
  • Rebooting has no effect.
  • Replacing the NIC with an older Intel 10/100 card had no effect.
  • Sending vendor-class-identifier to MSFT 5.0 in the DISCOVER packet:  no effect.
  • Doing a full factory reset, while making me redo all my rules and config did not fix the issue.
  • Temporarily flushed the iptables and set to accept, still no obtaining of the lease.

Here's the thing:  When I boot the machine with a Debian Live CD I have no issue temporarily editing its /etc/network/interfaces, setting the very same NIC to DHCP, ifup eth1 and bang, I'm connected fine.  In my mind this shows that my ISP is not doing something weird against Linux boxes, and that UTM is the issue.  When I do a tcpdump on the WAN interface, I can see the response packet from the ISP, Wiresharked the capture and verified its a good response, but UTM seems to be blocking or ignoring it.  I am at a loss.

As it stands, for the last few days I've been booting into the LiveCD to accept the lease, then reboot back into UTM and set the interface as static with the info from the ISP.  Their lease expires every 24 hours, at which time our Internet connection is dead until I do this process again.

Please help, I'd rather stay on UTM then go back to managing my firewall on a Debian build with scripts like I've done for the past 10 years.  Thanks to any and all who read this and might assist.

Grant



This thread was automatically locked due to age.
Parents
  • To anyone else hitting this issue:  I've worked around the problem by compiling a statically-linked dhclient binary on an ubuntu box, source downloaded from www.isc.org using version 4.1-ESV-R13., configured with flags supporting chroot.  After moving the binary onto my UTM and replacing the existing dhclient from /var/chroot-dhcpc/usr/sbin, everything appears to be working great.  I appreciate this will get blown away on an update, but can always replace with this older binary if the update still doesn't resolve my DHCP issues.  I acknowledge this is unsupported, but being on the home edition and using the source directly from ISC, I am comfortable with this hopefully short-term solution.

Reply
  • To anyone else hitting this issue:  I've worked around the problem by compiling a statically-linked dhclient binary on an ubuntu box, source downloaded from www.isc.org using version 4.1-ESV-R13., configured with flags supporting chroot.  After moving the binary onto my UTM and replacing the existing dhclient from /var/chroot-dhcpc/usr/sbin, everything appears to be working great.  I appreciate this will get blown away on an update, but can always replace with this older binary if the update still doesn't resolve my DHCP issues.  I acknowledge this is unsupported, but being on the home edition and using the source directly from ISC, I am comfortable with this hopefully short-term solution.

Children
No Data