ASA5510 - Verifying NAT is fully disabled between two interfaces

RandallMing · ‎06-25-2012

Hello,

I am trying to configure two inside interfaces without NAT. I am not using nat-control and I have added exemptions for the two networks. I can communicate between the two networks and to the Internet just fine.

I would like to verify that NAT is disabled between the two interfaces. I also need to make sure that the Interface IP (specifically for the traffic from inside-test to the inside network) is not added to packets between the two networks. I would like to be able to verify this as well. In other words I need to have the Source IP address from the originating connection on the inside-test network passed along through to the Inside network device without being replaced by the Interface's IP address. This is a test config for a production environment that will be using a load balancer. The config I have may be working in this regard and the load balancer may be replacing this IP address (that is what I am trying to test), but I am not certain.

So far I have the following NAT related running-config command (in regards to these two interfaces):

access-list NAT_Exempt extended permit ip 192.168.12.0 255.255.255.0 interface inside
access-list NAT_Exempt extended permit ip 192.168.3.0 255.255.255.0 interface Inside-test
access-list NAT_Exempt extended permit ip 192.168.12.0 255.255.255.0 192.168.3.0 255.255.255.0
access-list NAT_Exempt_2 extended permit ip 192.168.12.0 255.255.255.0 interface inside
access-list NAT_Exempt_2 extended permit ip 192.168.3.0 255.255.255.0 interface Inside-test
access-list NAT_Exempt_2 extended permit ip 192.168.3.0 255.255.255.0 192.168.12.0 255.255.255.0

nat (inside) 0 access-list NAT_Exempt_2
nat (inside) 1 0.0.0.0 0.0.0.0
nat (Inside-test) 0 access-list NAT_Exempt
nat (Inside-test) 1 0.0.0.0 0.0.0.0

global (outside) 1 interface
global (Inside-test) 1 interface

Let me know if more information is needed for you to assist me futher.

Thank you.

Jennifer Halim · ‎06-25-2012

Since you have NAT exemption configured: nat (inside) 0 access-list, it will take precedence over all your other NAT statement, so yes, traffic between the interfaces are exempted as configured.

If you need to be 100% certain, you can run packet tracer on the ASA and it will tell you exactly that it is NOT being NATed.

RandallMing · ‎06-26-2012

Hi Jennifer,

Thank you for your reply.

I have found out that the config above and when I make the following changes to the previous configuration no traffic is allowed from the inside network (3.X) to a site-to-site VPN connection. rebooting the ASA returns the everything to working order.

--

access-list student1_nonat extended permit ip 192.168.12.0 255.255.255.0 192.168.3.0 255.255.255.0

access-list student2_nonat extended permit ip 192.168.3.0 255.255.255.0 192.168.12.0 255.255.255.0

nat (student1) 0 access-list NAT_Exempt

nat (student2) 0 access-list NAT_Exempt_2

I also added the "same permit inter-interface" command with both of these inside networks at security level 100.

--

No other changes were made. It breaks connecting remotely to servers and https traffic across the VPN if not the entire connection.

I have rebooted the firewall to return it to the previous config and it works just fine in all regards.

Any ideas what would cause this and how to accomplish the original goal without breaking the vpn or other functions?

Jennifer Halim · ‎06-26-2012

You would need to share your whole config before you reboot your firewall to be able to tell what is incorrect.

The above config that you have seemed to be different to your original posted config, also, the access-list assigned to the NAT statement does not correspond to the ACL that you have configured (it has different names).

access-list student1_nonat extended permit ip 192.168.12.0 255.255.255.0 192.168.3.0 255.255.255.0

access-list student2_nonat extended permit ip 192.168.3.0 255.255.255.0 192.168.12.0 255.255.255.0

nat (student1) 0 access-list NAT_Exempt

nat (student2) 0 access-list NAT_Exempt_2

RandallMing · ‎06-27-2012

Hi Jennifer,

The different names is my fault, but they were entered correctly on the ASA. I did also vary slightly from the original post to see if that was what caused the problem initially however it broke in both cases.

Here is a good portion of my config with the changes:

REMOVED

Let me know if you see a problem that would cause it to break the VPN.

Also if you can provide details regarding how to verify that the traffic passing from one network to the other is not having the Interface IP address added to the packets that would greatly appreciated.

Thank you.

Jennifer Halim · ‎06-27-2012

Your NAT exemption ACL does not include the traffic towards the VPN tunnel, that's why it's breaking the VPN tunnel.

Pls add the following:

access-list NAT_Exempt_2 permit ip 192.168.3.0 255.255.255.0 69.87.157.192 255.255.255.224

access-list NAT_Exempt permit ip 192.168.12.0 255.255.255.0 69.87.157.192 255.255.255.224

You can run the command: show xlate detail

RandallMing · ‎06-27-2012

Thank you Jennifer for your responses.

Do I need to include access-list commands for both directions for each interface as listed in my full config above, or do I just need one for one direction on one and one direction on the other interface (plus the exempt for the 69.x.x.x network)?

Would this config suffice?

access-list NAT_Exempt_2 permit ip 192.168.3.0 255.255.255.0 192.168.12.0 255.255.255.0

access-list NAT_Exempt_2 permit ip 192.168.3.0 255.255.255.0 69.87.157.192 255.255.255.224

access-list NAT_Exempt permit ip 192.168.12.0 255.255.255.0 192.168.3.0 255.255.255.0

access-list NAT_Exempt permit ip 192.168.12.0 255.255.255.0 69.87.157.192 255.255.255.224

nat (inside) 0 access-list NAT_Exempt_2

nat (inside-test) 0 access-list NAT_Exempt

Will I need to clear xlate to see the results of this or will this take affect immediately? I can't really do that during business hours, but should be able to after hours if I need to.

Can you clarify what the global commands do? I keep thinking that it adds the IP of the Interface to packets as they go through the interface and that I should use a different config for the Inside-test network.

I will try the xlate detail to verify and let you know what I find.

Thank you.

Jennifer Halim · ‎06-27-2012

You don't need the access-list in both direction as NAT exemption (NAT 0 with ACL) works bi-directionally.

The above config is correct.

You might need to clear xlate if there is existing xlate created. Otherwise, it should work immediately.

The global command will get that PAT to the interface IP address for source IP which are NOT in the "NAT 0 ACL", or not in the Static NAT statement.

RandallMing · ‎06-28-2012

I have tried the suggested config and it breaks RDP from the VPN IP range 192.168.2.0 to the 192.168.3.0 (inside) interface.

Also I am not able to test the configuration I need because I am getting an "Inbound TCP connection denied from 192.168.3.45/80 to 192.168.12.100/49350 flags SYN ACK on interface DMZ" error when trying to use a website from one of the interfaces to another. This worked in my previous config, but now it doesn't. I don't know why it is showing the DMZ interface at all as I have the laptop browser on the 12.x network pointing to a domain on the 3.x network (using host file for testing). It works fine from the 3.x network to itself, but not from the 12.x network which it did with the config in my 3rd post.

I used packet tracer to check http and https traffic from the 12.x network to the 3.x network and vice versa. It passed the traffic both ways with no problems with the latest config in place, but the web page wouldn't load.

Any suggestions or ideas on either of these issues?

Jennifer Halim · ‎06-28-2012

Well, VPN Client is a new requirement, you didn't mention anything about VPN Client earlier

For VPN Client access, you would also need the following:

access-list NAT_Exempt_2 permit ip 192.168.3.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list NAT_Exempt permit ip 192.168.12.0 255.255.255.0 192.168.2.0 255.255.255.0

Not sure what you are trying for the DMZ. Traffic seems to return via DMZ interface, so you might want to check your VLAN or routing internally and make sure that it is routing correctly.

If packet tracer checks OK, it is not issue with the ASA.

RandallMing · ‎06-29-2012

Hi Jennifer,

Sorry for the confusion. I do not need the VPN client to connect to the new Inside-test network and did not realize that the changes we added to the inside network would change the status of the VPN client connectivity. I thought the two functions were separate and not related at all.

Should these new commands be "extended" permit or just permit? Is there a difference?

Any other potential issues you can see with the proposed config changing functionality from my current config with the exception of the 192.168.12.X network with no NAT?

Thank you for you help.

Jennifer Halim · ‎06-29-2012

You can configure it with or without the keyword "extended" as it accepts both. If you have protocol and port configured with source and destination IP, they are "extended" ACL, so it will take the command with or without the keyword "extended".

Don't think it will cause any issues as no NAT (NAT 0 with ACL) takes precedence over all other translation.