cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
474
Views
0
Helpful
4
Replies

NAT Problem

nohara
Level 1
Level 1

Hello,

I am having problems with all VPN users trying to access a web server on the DMZ please see attachment. The VPN users are on the 10.1.67.0\24 network and when I conduct a packet tracer to web server (10.1.24.25) it fails during NAT. The web server is being NAT'd to 50.xxx.xxx.xxx as you can see on the output below. CHComcast = Outside interface.

object network Web_Ingress
 nat (DMZ,CHComcast) static 50.xxx.xxx.xxx

So I figured that the NAT rule could be overriding the routing table so I tried to insert "route-lookup" but get an error.

nat (DMZ,CHComcast) static 50.xxx.xxx.xxx route-lookup
ERROR: Option route-lookup is only allowed for static identity case  

I'm not sure what else I can do. Any help would be greatly appreciated.

1 Accepted Solution

Accepted Solutions

JP Miranda Z
Cisco Employee
Cisco Employee

Hi nohara@ci.puyal,

If you VPN users is supposed to access the webserver with the private ip and not the natted ip you need to create a nat exempt so this traffic is not going to hit the dynamic nat:

nat (dmz,CHComcast) 1 source static obj-10.1.24.25 obj-10.1.24.25o destination staticbj-10.1.67.0\24 obj-10.1.67.0\24  no-proxy-arp route-lookup

This is just an example you need to use the real objects or create them.

That should definitely fix your problem.

If you don't want to exempt this traffic because your VPN users are supposed to reach that server by the public ip you need to do the packet tracer with the destination as the public ip.

Hope this info helps!!

Rate if helps you!! 

-JP-

View solution in original post

4 Replies 4

JP Miranda Z
Cisco Employee
Cisco Employee

Hi nohara@ci.puyal,

If you VPN users is supposed to access the webserver with the private ip and not the natted ip you need to create a nat exempt so this traffic is not going to hit the dynamic nat:

nat (dmz,CHComcast) 1 source static obj-10.1.24.25 obj-10.1.24.25o destination staticbj-10.1.67.0\24 obj-10.1.67.0\24  no-proxy-arp route-lookup

This is just an example you need to use the real objects or create them.

That should definitely fix your problem.

If you don't want to exempt this traffic because your VPN users are supposed to reach that server by the public ip you need to do the packet tracer with the destination as the public ip.

Hope this info helps!!

Rate if helps you!! 

-JP-

Appreciate the reply JP!

So lets say my VPN users subnet object is obj-10.1.67.0 and the web server object is obj-10.1.24.25

Does the below look correct? I'm assuming the number 1 means the rule will be applied to the top of the list?

nat (dmz,CHComcast) 1 source static obj-10.1.24.25 obj-10.1.24.25 destination static obj-10.1.67.0 obj-10.1.67.0 no-proxy-arp route-lookup

nohara@ci.puyal,

You can also add the nat without the number 1, and yes is to put it on top, and also yes that nat will fix the issue.

Hope this info helps!!

Rate if helps you!! 

-JP-

I've been doing some researching and I think it's the other way around.

nat (dmz,CHComcast) 1 source static obj-10.1.67.0 obj-10.1.67.0 desitnation static obj-10.1.24.25 obj-10.1.24.25 no-proxy-arp route-lookup

obj-10.1.67.0 = VPN Subnet

obj-10.1.24.25 = DMZ Web server

Review Cisco Networking for a $25 gift card