cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
587
Views
0
Helpful
5
Replies

IOS NAT quirk

tmarlow
Level 1
Level 1

I have a 2620 configured with NAT overloading, which works. I also have a static NAT for a web server, which works for access from the outside of the router. I'm on the inside of the network trying to go to the web server which is also on the internal network, but I'm trying to get to it via the "global ip address". It doesn't work, why? Can I change something. I have:

int fa0/0

ip address 10.0.0.1 255.255.255.0

ip nat outside

!

int fa0/1

ip address 192.168.1.1 255.255.255.0

ip nat inside

!

ip nat inside source list 1 interface FastEthernet0/0 overload.

ip nat inside source static 192.168.1.10 10.0.0.10

!

access-list 1 permit 192.168.1.0 0.0.0.255

!

***192.168.1.10 is the web server and I have a host on the 192.168.1.0 network using a browser to "http://10.0.0.10.

***

5 Replies 5

thisisshanky
Level 11
Level 11

Because the translation happens only if the packet is received on the outside interface. Since you are trying to reach it via global IP from the inside interface the translation will never happen.

A workaround is to have your local DNS server resolve the DNS name of web server ot the local IP and not global IP. From the internet let your ISP handle translation of DNS name of web server to the appropriate global IP.

Sankar Nair
UC Solutions Architect
Pacific Northwest | CDW
CCIE Collaboration #17135 Emeritus

I have some debugging that says the translation is happening and it looks like its responding to the host, but alas, nothing in the browser. This bothers me because their is a Netopia router that is doing this fine. Look at this debugging from when the internal host tries to use the inside global to access the internal web server:

05:04:48: NAT: s=192.168.1.102->10.0.0.1, d=10.0.0.10 [16574]

05:04:48: NAT: s=10.0.0.10, d=10.0.0.1->192.168.1.102 [658]

05:04:49: NAT: s=192.168.1.102->10.0.0.1, d=10.0.0.10 [16580]

05:04:49: NAT: s=10.0.0.10, d=10.0.0.1->192.168.1.102 [659]

05:04:49: NAT: s=192.168.1.102->10.0.0.1, d=10.0.0.10 [16585]

05:04:49: NAT: s=10.0.0.10, d=10.0.0.1->192.168.1.102 [660]

The PAT (overloaded) translation does take place as it matches the policy you have configured in the overload line:

- input interface is marked with "ip nat inside";

- source IP address matches access-list 1;

- output interface is fa0/0

- output interface is marked with "ip nat outside"

As far as I understand, once the packet has been PAT-ted, you expect it to be static NAT-ted and routed back to the inside interface.

Well, this cannot occur as the packet does not match the static nat policy you configured. A basic requirement of the policy you configured is that the packet shall flow between the outside and the inside interface, while what you are expecting is that the packet enters and exits the same interface.

If there is a compelling reason for not accepting Sankar's advise, you could turn to the NAT-on-a-stick configuration. Please check it out here:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml

HTH

michele

I was looking at the NAT-on-a-stick article. I can't figure out how to trick the inside host(s) that are trying to go to the global IP into NATing the destination to the inside IP. Any ideas or config examples?

I would try this configuration (see Example 2 of the Nat-on-a-stick doc), that requires you to change the subnet on fa0/0:

int fa0/0

ip address 172.16.0.1 255.255.255.0

ip nat outside

ip policy route-map Nat

!

int fa0/1

ip address 192.168.1.1 255.255.255.0

ip nat outside

no ip redirects

ip policy route-map Nat

!

int loop 0

ip address 10.0.0.1 255.255.255.0

in nat inside

!

ip nat inside source list 1 interface loo0 overload

ip nat outside source static 10.0.0.10 192.168.1.10

!

access-list 1 permit 192.168.1.0 0.0.0.255

!

access-list 101 permit ip 192.168.1.0 0.0.0.255 any

access-list 101 permit ip any host 10.0.0.10

!

route-map Nat permit 10

match ip address 101

set int loop0

!

If this does not work (I haven't tested it), try to follow the packet flow as described by the document and make changes accordingly.

HTH

michele