DHCP not working when NAT is enabled.
CodeBlox
Member Posts: 1,363 ■■■■□□□□□□
in CCNA & CCENT
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:
====
====
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
Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
Comments
-
m3zilla
Member Posts: 172
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
Member Posts: 1,363 ■■■■□□□□□□
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.Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
-
CodeBlox
Member Posts: 1,363 ■■■■□□□□□□
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?Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
-
spd3432
Member Posts: 224
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.----CCNP goal----
Route [ ] Studying
Switch [ ] Next
Tshoot [ ] Eventually -
CodeBlox
Member Posts: 1,363 ■■■■□□□□□□
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.Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
-
MickQ
Member Posts: 628 ■■■■□□□□□□
Sorry Codeblox, I've only done it on different subnets without any NAT. -
georgemc
Member Posts: 429
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.
GeorgeWGU BS: Business - Information Technology Management
Start Date: 01 October 2012
QFT1,PFIT in progress.
TRANSFERRED/COMPLETED: AGC1,BBC1,LAE1,QBT1,LUT1,QLC1,QMC1,QLT1,IWC1,INC1,INT1,BVC1,CLC1,MGC1, CWV1 BNC1, LIT1,LWC1,QAT1,WFV1,EST1,EGC1,EGT1,IWT1,MKC1,MKT1,RWT1,FNT1,FNC1, BDC1,TPV1 REQUIRED: -
CodeBlox
Member Posts: 1,363 ■■■■□□□□□□
Right... So is there a remedy for my situation with NAT or is this a no-no.Currently reading: Network Warrior, Unix Network Programming by Richard Stevens
-
ayori
Member Posts: 48 ■■□□□□□□□□
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
Member Posts: 4,024
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 -
georgemc
Member Posts: 429
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.WGU BS: Business - Information Technology Management
Start Date: 01 October 2012
QFT1,PFIT in progress.
TRANSFERRED/COMPLETED: AGC1,BBC1,LAE1,QBT1,LUT1,QLC1,QMC1,QLT1,IWC1,INC1,INT1,BVC1,CLC1,MGC1, CWV1 BNC1, LIT1,LWC1,QAT1,WFV1,EST1,EGC1,EGT1,IWT1,MKC1,MKT1,RWT1,FNT1,FNC1, BDC1,TPV1 REQUIRED: -
Forsaken_GA
Member Posts: 4,024
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
Member Posts: 429
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... 
WGU BS: Business - Information Technology Management
Start Date: 01 October 2012
QFT1,PFIT in progress.
TRANSFERRED/COMPLETED: AGC1,BBC1,LAE1,QBT1,LUT1,QLC1,QMC1,QLT1,IWC1,INC1,INT1,BVC1,CLC1,MGC1, CWV1 BNC1, LIT1,LWC1,QAT1,WFV1,EST1,EGC1,EGT1,IWT1,MKC1,MKT1,RWT1,FNT1,FNC1, BDC1,TPV1 REQUIRED: -
ayori
Member Posts: 48 ■■□□□□□□□□
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
Member Posts: 48 ■■□□□□□□□□
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
Mod Posts: 11,962 Mod
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.An expert is a man who has made all the mistakes which can be made. -
ayori
Member Posts: 48 ■■□□□□□□□□
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
Mod Posts: 11,962 Mod
It would get back via NAT, but as pointed out in this thread this isn't a routing problem.An expert is a man who has made all the mistakes which can be made.
-
ayori
Member Posts: 48 ■■□□□□□□□□
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
Mod Posts: 11,962 Mod
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.An expert is a man who has made all the mistakes which can be made.
-
ayori
Member Posts: 48 ■■□□□□□□□□
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
Member Posts: 107
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.
-
CodeBlox
Member Posts: 1,363 ■■■■□□□□□□
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.Currently reading: Network Warrior, Unix Network Programming by Richard Stevens -
Forsaken_GA
Member Posts: 4,024
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
Member Posts: 4,024
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
Member Posts: 48 ■■□□□□□□□□
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.
