02-23-2011 11:02 AM - edited 03-11-2019 12:55 PM
Hello,
We have added another outside network on int 0/3, but we can't get the NAT working. Any request from that subnet on that new int 10.40.86.xx to lets say 10.40.86.31 port 80 which should NAT to 172.30.1.31. The setup is pretty much the same as the original outside int. Could anyone tell me what I am missing here? Please see attached.
Please kindly advise.
Thank you.
Solved! Go to Solution.
02-23-2011 12:01 PM
Hello,
Can you please repeat the packet-tracer command, but do not use your E-40 interface IP as the client since this is not valid. The client will be some other PC in the 10.40.86.x subnet, correct? For example:
packet-tracer in E-40 tcp 10.40.86.10 12345 10.40.86.31 80
Also, you may be running into an asymmetric NAT rule problem because of this NAT 0 line:
access-list inside_nat0_outbound extended permit ip 172.30.0.0 255.255.0.0 object-group DM_INLINE_NETWORK_1
You should make that rule more specific, but to test in the mean time, you could add a line like this:
access-list inside_nat0_outbound line 1 extended deny tcp host 172.30.1.31 10.40.86.0 255.255.255.0
That will allow NAT to take place when 172.30.1.31 talks to the 10.40.86.0 subnet.
-Mike
02-23-2011 11:20 AM
Hello,
Is there a reason you have this route configured?
route E-40 10.40.86.0 255.255.255.0 10.40.86.249
When the ASA sends the response back to the 10.40.86.xx client, it's going to send it to 10.40.86.249 rather than directly back to the client which should be directly connected in the 10.40.86.x subnet.
If the connection still doesn't work after removing that route, please run this command and paste the output for us:
packet-tracer in E-40 tcp 10.40.86.xx 12345 10.40.86.31 80
Also, check for any syslogs that might be generated when the connection fails.
-Mike
02-23-2011 11:28 AM
Hi mirober2,
I have removed the route which yields the same result. This is the result from packet trace:
ciscoasa# packet-tracer in E-40 tcp 10.40.86.248 12345 10.40.86.31 80
Phase: 1
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow
Phase: 2
Type: UN-NAT
Subtype: static
Result: ALLOW
Config:
static (inside,E-40) tcp 10.40.86.31 www 172.30.1.31 www netmask 255.255.255.255
nat-control
match tcp inside host 172.30.1.31 eq 80 E-40 any
static translation to 10.40.86.31/80
translate_hits = 0, untranslate_hits = 7
Additional Information:
NAT divert to egress interface inside
Untranslate 10.40.86.31/80 to 172.30.1.31/80 using netmask 255.255.255.255
Phase: 3
Type: ACCESS-LIST
Subtype:
Result: DROP
Config:
Implicit Rule
Additional Information:
Result:
input-interface: E-40
input-status: up
input-line-status: up
output-interface: inside
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule
02-23-2011 12:01 PM
Hello,
Can you please repeat the packet-tracer command, but do not use your E-40 interface IP as the client since this is not valid. The client will be some other PC in the 10.40.86.x subnet, correct? For example:
packet-tracer in E-40 tcp 10.40.86.10 12345 10.40.86.31 80
Also, you may be running into an asymmetric NAT rule problem because of this NAT 0 line:
access-list inside_nat0_outbound extended permit ip 172.30.0.0 255.255.0.0 object-group DM_INLINE_NETWORK_1
You should make that rule more specific, but to test in the mean time, you could add a line like this:
access-list inside_nat0_outbound line 1 extended deny tcp host 172.30.1.31 10.40.86.0 255.255.255.0
That will allow NAT to take place when 172.30.1.31 talks to the 10.40.86.0 subnet.
-Mike
02-23-2011 12:43 PM
Thanks Mike,
The line
access-list inside_nat0_outbound extended permit ip 172.30.0.0 255.255.0.0 object-group DM_INLINE_NETWORK_1
was the problem, I've remove it and it works now.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide