DHCP not working when NAT is enabled.

I have the following scenario. I have two lans separated by three routers. LAN A contains a host and LAN B contains a DHCP server (WS2K

running the DHCP service. I have Router A configured with a helper address so that my LAN broadcast for DHCP are sent to the server on the second LAN. This works when I do not have NAT enabled. Once I enable NAT, it stops working and I don't get an address. I took a look at this in wireshark and it's as if the server doesn't even respond with an ACK when using NAT. Does DHCP not work through NAT? I did a show ip nat trans and NAT is working as expected. See below for configs and screenshots.

Here is the topology:

Here is my wireshark log to further show what I mean:

Notice how where it shows the source being 10.0.0.1 go through the phases of DHCP while the ones sourced from 12.0.0.1 (RTR A's serial int) keep sending Discover datagrams.

Here are the configs:

LAN_A#show run
Building configuration...

*Mar  1 00:58:24.107: %SYS-5-CONFIG_I: Configured from console by console
Current configuration : 1196 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname LAN_A
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
 ip address 10.0.0.1 255.255.255.0
 ip helper-address 13.0.0.2
 ip nat inside
 ip virtual-reassembly
 speed 100
 full-duplex
!
interface Serial0/0
 ip address 12.0.0.1 255.255.255.252
 ip nat outside
 ip virtual-reassembly
 clock rate 2000000
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 no ip address
 shutdown
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 network 12.0.0.1 0.0.0.0 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
ip nat inside source list 100 interface Serial0/0 overload
!
access-list 100 permit ip 10.0.0.0 0.0.0.255 any
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
!
end

====

A_B#show run
Building configuration...

Current configuration : 984 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname A_B
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/0
 ip address 12.0.0.2 255.255.255.252
 clock rate 2000000
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 ip address 12.0.0.5 255.255.255.252
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 network 12.0.0.2 0.0.0.0 area 0
 network 12.0.0.5 0.0.0.0 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
!
end

====

LAN_B#show run
Building configuration...

Current configuration : 985 bytes
!
version 12.4
service timestamps debug datetime msec
service timestamps log datetime msec
no service password-encryption
!
hostname LAN_B
!
boot-start-marker
boot-end-marker
!
!
no aaa new-model
memory-size iomem 5
ip cef
!
!
!
!
no ip domain lookup
ip auth-proxy max-nodata-conns 3
ip admission max-nodata-conns 3
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
!
interface FastEthernet0/0
 ip address 13.0.0.1 255.255.255.248
 speed 100
 full-duplex
!
interface Serial0/0
 ip address 12.0.0.6 255.255.255.252
 clock rate 2000000
!
interface FastEthernet0/1
 no ip address
 shutdown
 duplex auto
 speed auto
!
interface Serial0/1
 no ip address
 shutdown
 clock rate 2000000
!
router ospf 1
 log-adjacency-changes
 network 12.0.0.6 0.0.0.0 area 0
 network 13.0.0.1 0.0.0.0 area 0
!
ip forward-protocol nd
!
!
no ip http server
no ip http secure-server
!
!
!
!
control-plane
!
!
!
!
!
!
!
!
!
!
line con 0
 exec-timeout 0 0
 logging synchronous
line aux 0
line vty 0 4
 login
!
!
end

topology.jpg

DHCP.jpg

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

drkat

do a port forward for 68/67 UDP ports

m3zilla

I haven't setup a DHCP server in a while, but I vaguely remember specifying which network it's servicing when setting one up.

CodeBlox

The DHCP request are getting to the DHCP server. The server just isn't giving an ACK and so on. I think it's because the data is sourced from 12.0.0.1(because of NAT) instead of 10.0.0.0 and there is no pool for 12.0.0.0. Could be something wrong with my DHCP config in windows 2008.

CodeBlox

BUMP... So I know that DHCP is possible when the server isn't on the same subnet as this works without NAT. But is what I'm trying to do considered a bad practice? I intended to have my DHCP server on a remote LAN that crosses over the internet and have my clients pull their private IP addresses from it. Seems like NAT prevents it. Anyone?

spd3432

I don't know if its bad practice or just won't work. I recall from my M$ studies having DHCP servers on the same segment as the clients, on different network segments within a LAN, and on different segments on a WAN. I don't recall ever setting up a Windows NAT server then trying to pass DHCP traffic through it. I did pass DHCP traffic across a WAN link after configuring a site-to-site VPN though.

CodeBlox

Thanks for the response. It's looking more and more to me like it shouldn't be done this way. If I get no more input here, I'll have to wait til work on Tuesday and ask the Cisco folks there.

MickQ

Sorry Codeblox, I've only done it on different subnets without any NAT.

georgemc

CodeBlox wrote: »

Thanks for the response. It's looking more and more to me like it shouldn't be done this way. If I get no more input here, I'll have to wait til work on Tuesday and ask the Cisco folks there.

DHCP is working as advertised. This isn't really a Cisco question, it is a DHCP relay question and you have to understand the purpose of DHCP relay and the basics of how it works.

This is worded a bit more eloquently than I could put it:

"With an IP helper-address in place, the router forwards packets on to the designated server. When this occurs, the encapsulated packet can be identified as originating from the network segment where the router was. Responses sent back are again intercepted by the router and passed to the workstation just as if the transaction were happening locally. On the DHCP server, separate subnet records need to be set up. Within each subnet, a range of addresses to allocate is specified. Again, the DHCP server will learn the appropriate subnet to allocate from based on the IP address of the router forwarding the packets."

How do clients find a DHCP server on another subnet? - Cisco: Routers FAQ - Tek-Tips

Since you are NATting, your DHCP server receives a discovery from a subnet (12.0.0.X) that is not in it's range of available scopes so it does not respond because the request is coming from a subnet that it is not responsible for.

Setting up a scope for the 12.0.0.X network would not work either since your host is connected to the interface with address 10.0.0.1 on your router and the host address needs to be within the interface range.

George

CodeBlox

Right... So is there a remedy for my situation with NAT or is this a no-no.

ayori

Hmm.. add a deny statement on your NAT acl?
LAN_A:
no access-list 100 permit ip 10.0.0.0 0.0.0.255 any
access-list 100 deny ip host 10.0.0.1 host 13.0.0.2
access-list 100 permit ip 10.0.0.0 0.0.0.255 any

Forsaken_GA

What the others have said is correct, you're NAT'ing your traffic, and unless you have a scope for the subnet that the source is being translated from, the DHCP server is going to tell you to go frotz yourself.

I would not do it like this, it's incredibly bad design. Either find a way to not need the NAT, or locate a DHCP server that the hosts can access without needing to go through a NAT.

Assuming the subnet that needs to be NAT'd isn't large, I'd recommend having the router doing the NAT act as the DHCP server for that scope

halaakajan

Relay Agent or BootP Router would be a solution if I am not mistaken.

georgemc

Forsaken_GA wrote: »

Assuming the subnet that needs to be NAT'd isn't large, I'd recommend having the router doing the NAT act as the DHCP server for that scope

+1 on that. I also second that it is very bad design.

Forsaken_GA

halaakajan wrote: »

Relay Agent or BootP Router would be a solution if I am not mistaken.

No, the problem here is the lack of a route back. The way it works is this -

The NAT router receives the DHCP broadcast on it's nat inside interface, which has a helper-address configured. The helper-address converts the DHCP broadcast to a unicast and forwards it to the DHCP server. All good.

DHCP server receives the unicast, source address will be from the router doing the NAT's nat outside interface. Again, no problem.

Where the problem comes in is how the reply packet is constructed. The DHCP server looks at the GIADDR field in the DHCP packet, this will have an ip address of the interface on the router that has the ip helper-address configured... which is the nat inside interface. So the destination that the DHCP server will send to is behind the NAT, but since it's behind the NAT, you can't unicast to it. Hence, DHCP failure.

You probably actually could make this work with a static route on the DHCP host, but that sort of defeats the purpose of the NAT.

georgemc

Forsaken_GA wrote: »

No, the problem here is the lack of a route back. The way it works is this -

DHCP server receives the unicast, source address will be from the router doing the NAT's nat outside interface. Again, no problem.

Where the problem comes in is how the reply packet is constructed. The DHCP server looks at the GIADDR field in the DHCP packet, this will have an ip address of the interface on the router that has the ip helper-address configured... which is the nat inside interface. So the destination that the DHCP server will send to is behind the NAT, but since it's behind the NAT, you can't unicast to it. Hence, DHCP failure.

Forsaken_GA

Thanks for motivating me to go back and review the DHCP RFCs.

It looks like I missed a step there...

ayori

I may be missing something here but if the DHCP server's default gateway is LAN_B and both LAN_B and A-B routers have a route to 10.0.0.0/24 network, then all should be good right? Just add the nonat on LAN_A no?

ayori

ayori wrote: »

Hmm.. add a deny statement on your NAT acl?
LAN_A:
no access-list 100 permit ip 10.0.0.0 0.0.0.255 any
access-list 100 deny ip host 10.0.0.1 host 13.0.0.2
access-list 100 permit ip 10.0.0.0 0.0.0.255 any

Just tried your topology on packet tracer and PC was able to get a DHCP address with the above nonat. Just had to add network 10.0.0.0 on your ospf process 1 on LAN_A so LAN_B knows how to send the DHCP packets back from the server.

networker050184

This isn't a real world solution though. You aren't going to be able to just advertise your private LAN space over the internet. IF you are in the situation where you can advertise the space over then there is no need for NAT anyway.

ayori

Right and I assumed this is not a real world topology as how would the DHCP offer get back from the server if the destination IP is 10.0.0.1?

networker050184

It would get back via NAT, but as pointed out in this thread this isn't a routing problem.

ayori

The DHCP server's reply will never get back to LAN_A router not because the destination (10.0.0.1) is behind a NAT, but rather LAN_B router doesn't have a route entry to the 10 subnet.

My point is with or without NAT, this will never work unless LAN_B and A-B routers know how to get to 10.0.0.0/24.

Without NAT, what is the source address of the first DHCP packet that LAN_A will pass to A-B?
10.0.0.1.
Therefore, replies by the DHCP server will have a destination of 10.0.0.1 (assuming private addresses are able to traverse the WAN). How would LAN_A receive the reply of LAN_B doesn't even know how to get to 10.0.0.0/24? Packet gets dropped by LAN_B. DHCP fails.

With NAT, the source address will be 12.0.0.1. DHCP server gets it and finds no DHCP scope for the 12 subnet. DHCP fails.

I'm not entirely sure how the OP got this to work without NAT (as he stated) with just the above posted config (no routes for the 10 subnet).

networker050184

Well obviously you need routes for communication to happen, but the moral of the story here is that it isn't a routing or communication issue, its an application issue. The router has no problem routing these packets (assuming OP configures routing correctly) as it frankly doesn't care what's inside at this point. The DHCP server on the other hand does.

ayori

I totally agree with you and that is why my first post is just a suggestion on how the OP can keep his NAT while the PC is able to pick up an IP for the DHCP server (don't NAT the DHCP request), ignoring anything about routing. I understand that you aren't going to be advertising your private LAN space over the Internet. The only reason I said I added the network 10.0.0.0 on the router ospf process is because the OP didn't have anything in his config that would make LAN_B and A-B routers aware of the 10 subnet.

I never said that advertising the 10 subnet is the solution to his problem.

My suggestion is just plain and simple - if the PC is not able to get an IP because of NAT, then don't NAT the DHCP request.

Mstavridis

I know this is outside the scope of CCNA but well this is how I do it at work, GRE... coupled with IPSEC. But in your case all you need is the GRE part.

kurosaki00

very educative thread!
Thanks ppl

CodeBlox

ayori wrote: »

I totally agree with you and that is why my first post is just a suggestion on how the OP can keep his NAT while the PC is able to pick up an IP for the DHCP server (don't NAT the DHCP request), ignoring anything about routing. I understand that you aren't going to be advertising your private LAN space over the Internet. The only reason I said I added the network 10.0.0.0 on the router ospf process is because the OP didn't have anything in his config that would make LAN_B and A-B routers aware of the 10 subnet.

I never said that advertising the 10 subnet is the solution to his problem.

My suggestion is just plain and simple - if the PC is not able to get an IP because of NAT, then don't NAT the DHCP request.

If I did what you're suggesting, as pointed out by others here, there would be no need for NAT. My intent was to sorta simulate a network where the DHCP server is somewhere reached using the internet and have my local clients pull their private addresses via that DHCP server.

Forsaken_GA

ayori wrote: »

My point is with or without NAT, this will never work unless LAN_B and A-B routers know how to get to 10.0.0.0/24.

Which is exactly what the OP said. Without NAT, it works fine. With NAT, it doesn't. Without NAT, there is a presumption that the route is being propagated.

The problem is simple - due to the way DHCP works, with how it fills out it's headers, the DHCP server is going to send the Reply back to the router interface that translated it from a broadcast and a unicast. If that interface is NAT'd (which generally means you do NOT have a direct route to the subnet being NAT'd, if you do, you're a very bad network designer), then the unicast reply will be dropped, as it's destination is not reachable.

As I said, this probably could be solved with a static route on the DHCP server, but having routes to your NAT'd networks is pointless, no need for the NAT anymore

Forsaken_GA

Mstavridis wrote: »

I know this is outside the scope of CCNA but well this is how I do it at work, GRE... coupled with IPSEC. But in your case all you need is the GRE part.

Indeed, tunnels are the duct tape of the network engineers toolkit, and they can solve alot of problems.

ayori

CodeBlox wrote: »

If I did what you're suggesting, as pointed out by others here, there would be no need for NAT. My intent was to sorta simulate a network where the DHCP server is somewhere reached using the internet and have my local clients pull their private addresses via that DHCP server.

Understood. What confused me is if you're really simulating DHCP traffic over the Internet, then why would your Wireshark capture have source IPs of 10.0.0.1 reaching the DHCP server over the WAN? Those packets would be dropped right at the ISP router (which is A-B in this case) as the source is from a private LAN space.

With your posted config minus the NAT statements and ACL, how was your PC able to get an IP from the server?

Unless you're using something like IPSec over GRE tunnels then your packet would never traverse the Internet without NAT contrary to what you said in the original post that the config works without NAT.

Forsaken_GA

ayori wrote: »

Understood. What confused me is if you're really simulating DHCP traffic over the Internet, then why would your Wireshark capture have source IPs of 10.0.0.1 reaching the DHCP server over the WAN? Those packets would be dropped right at the ISP router (which is A-B in this case) as the source is from a private LAN space.

With your posted config minus the NAT statements and ACL, how was your PC able to get an IP from the server?

Unless you're using something like IPSec over GRE tunnels then your packet would never traverse the Internet without NAT contrary to what you said in the original post that the config works without NAT.

Right, this is why this type of setup is normally done with a tunnel across the public internet, or across private WAN circuits. Trying to connect your sites over the public internet using NAT is a bad idea