1

Topology:

[PC1]---lan----[RT1 / DHCP relay / DNAT]---wan---[DHCP server]
[PC2]---------/ /
[PC3]----------/
  • DHCP relay makes the a DHCP broadcast into a unicast and
  • Forwards it to the DHCP server which
  • Then responds and sends a DHCP reply which
  • Reaches PC1.

However PC1 saves the DHCP server information in it's network config. Then, when half-lease time has come, it requests a new address using unicast directly from the DHCP server.

Problem: The source IP is the PC1 IP (no source nat). So the DHCP server sets the destination IP as the IP of PC1 - which gets dropped on the router.

Question: What is the common solution to this problem? Source NAT configuration? What are some other ways to solve it?

  • 2
    I doubt there's a "common" solution to this problem since it's not a common setup. VPN is probably the way to go. – JFL Mar 15 '18 at 9:22
  • @JFL - wondering if adding source NAT into the mix would help? WDYT – Mindaugas Bernatavičius Mar 15 '18 at 12:41
  • I doubt it since the packet will not come from the IP attributed to the lease, but I didn't check how lease renewal works with DHCP relay. – JFL Mar 15 '18 at 13:00
2

I think there's something wrong in the router configuration because this should probably work.

When the client PC has no IP address at all, it broadcasts, and the router is able to unicast the request over to the DHCP server using its LAN interface, right? So obviously the DHCP server is able to reply back to the router's LAN interface. So why should it be any different for the PC to do the same thing when lease renewal time comes? The router should NAT it through and the reply from the DHCP server should come back through the NAT. If it doesn't, then I think you have something wrong on the router. You should check that UDP is permitted back through the router. And if the router has any kind of firewall on it, check that it is following UDP connections, to allow them to return back through the firewall.

Other ways to solve this problem are:

  1. A GRE tunnel
  2. A VPN tunnel
  3. Putting DHCP on the router
  4. Deploying a local DHCP server
  5. Removing the NAT, or at least modifying the NAT so that traffic between clients and DHCP are not NATed
  • Thanks a lot. I was told the the lease renewal does not come back since the source IP is not of the DHCP relay, but the end PC issuing the DHCP renewal request. I thought that SRC NAT (rewritting the source IP) would help, but have not tested that. What do you think? – Mindaugas Bernatavičius Apr 3 '18 at 9:49
  • Perhaps there's a firewall in the path that is blocking the reply, but that's only a guess. You should do a packet capture at the router's WAN port to see if the reply makes it back. Changing from dst nat to src nat shouldn't change anything. The only nat scenario that would be bad is if the server is dynamic PAT toward the client, but your description sounds like that is not the issue. – user3629081 Apr 3 '18 at 13:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.