DHCP on outside interface with NAT

[sngrindrod]

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.

[Reza Sharifi]

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

HTH

[Jon Marshall]

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

[sngrindrod]

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

[cadet alain]

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

[theunfcco]

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

!

[Richard Burts]

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.

[theunfcco]

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?

[Richard Burts]

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?

[theunfcco]

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.