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

Problem with NAT on ASA5510

kpoon
Level 1
Level 1

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.

1 Accepted Solution

Accepted Solutions

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

View solution in original post

4 Replies 4

mirober2
Cisco Employee
Cisco Employee

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

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

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

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.

Review Cisco Networking for a $25 gift card