cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
20766
Views
10
Helpful
9
Replies

DHCP on outside interface with NAT

sngrindrod
Level 1
Level 1

House network 2.gif

What "IP NAT POOL" is used if my outside interface has an IP of DHCP.  Im using a 2611 with 12.4(25c).  IOS will only allow an actual IP.

9 Replies 9

Reza Sharifi
Hall of Fame
Hall of Fame

Do a "sh ip arp" an the NAT router.  That should tell you the IP address you are using.

HTH

Jon Marshall
Hall of Fame
Hall of Fame

Simon

Do you mean to NAT your internal devices so they can get to the internet ?  I'm assuming so because you mention using a NAT pool.

If so you shouldn't need to know the IP and indeed it could change anyway. Would this config not work  -

access-list 101 permit ip any any  <-- note you can replace the first "any" with the specific 192.168.x.x addresses if you want

ip nat inside source list 101 interface fa0/0 overload

If i have misunderstood then let me know.

Jon

Ref page 676 Sybex CCNA Study Guide.

ip nat pool globalnet ???.???.???.???  ???.???.???.??? (im using dhcp from the isp, Cisco IOS will not allow "dhcp". this sis where I'm stuck)

netmask 255.255.255.0

ip nat inside source list 1 pool globalnet overload

int f0/0

ip address dhcp

ip nat outside

int f0/1

ip address 192.168.2.1 255.255.255.252

ip nat inside

int s0/0

192.168.2.6 255.255.255.252

ip nat inside

access-list 1 permit any any

Thanks for your help

Si

sigrindrod@knology.net

Hi,

Do as jon suggested, don't use the nat pool command and specify the interface instead in the ip nat inside source command.Even if you knew the IP address, when you receive a new one from DHCP it will stop working if you use the nat pool command.

Regards.

Alain

Don't forget to rate helpful posts.

I'm using this and it's working fine :

 

interface GigabitEthernet1

description External interface with DHCP

ip address dhcp

ip nat outside

negotiation auto

!

interface GigabitEthernet2

description Trunk interface

no ip address

negotiation auto

!

interface GigabitEthernet2.111

description Vlan 111

encapsulation dot1Q 111

ip address 192.168.111.1 255.255.255.0

ip nat inside

!

interface GigabitEthernet2.121

description Vlan 121

encapsulation dot1Q 121

ip address 192.168.121.1 255.255.255.0

ip nat inside

!

interface GigabitEthernet2.131

description Vlan 131

encapsulation dot1Q 131

ip address 192.168.131.1 255.255.255.0

ip nat inside

!         

interface GigabitEthernet2.141

description Vlan 141

encapsulation dot1Q 141

ip address 192.168.141.1 255.255.255.0

ip nat inside

!         

interface GigabitEthernet3

no ip address

shutdown

negotiation auto

!         

ip nat inside source list 100 interface GigabitEthernet1 overload extended

ip forward-protocol nd

!         

no ip http server

no ip http secure-server

!         

access-list 100 remark NAT DHCP Access-list

access-list 100 permit ip 192.168.111.0 0.0.0.255 any log

access-list 100 permit ip 192.168.121.0 0.0.0.255 any log

access-list 100 permit ip 192.168.131.0 0.0.0.255 any log

access-list 100 permit ip 192.168.141.0 0.0.0.255 any log

!

Thanks for sharing your experience. I am glad that this is working fine for you. I do have a couple of comments about the access list you are using. I have seen some odd things happen when an access list that is used for something other than access-group and includes the log parameter. (the log parameter works well when the access list is applied with access-group but some times not well when the access list is used some other way). Also I know that the original discussion did suggest using an extended access list, but I have seen some unexpected behaviors when an extended access list used for address translation specified any as the destination. Your access list is not looking for any destination addresses and is not looking for any protocol ports and so there is no benefit from using an extended access list for your address translation. I wold suggest that you rewrite the access list and use a standard acl.

HTH

Rick

Will consider that, thanks!

 

Note that I avoided something more simple as need to connect from the outside to the external IP, like for ssh, and although not specifying dest/services, that will be ready for that later.

 

What you did mentioned about log not working all times... does it affect NAT process or only does not log all the times?

I am concerned about the possibility that NAT could be affected. 

 

I do not understand your comment about "although not specifying dest/services, that will be ready for that later."  Are you suggesting that you do have plans to change and to not translate for certain destinations or for certain protocol ports?

HTH

Rick

Yes. I used that config to solve current need and future ones.

 

As a simple change could be done only at ACL level and dont have to go thru a complete config analisys, create a new acl to the replace the one in use at nat statement, etc.

 

I know that in the field thats being used in a daily basis but thats also something that leads to leave more and more trash in configs that always require further cleanup.

 

In my configs I always plan how to keep it for long term use, managed by others and also considering 3rd parties automation tools.

 

But if the log or acl type have caveats that impacts on the NAT process, thats might be a bug issue or IOS should not allow us to use that way. 

Review Cisco Networking for a $25 gift card