Static Policy NAT in VPN conflicts with Static NAT

[mct234]

I have a situation where I need to create a site-to-site VPN between an ASA 5505 using IOS 7.2 and a Sonicwall NSA4500. The problem arises in that the LAN behind the Cisco ASA has the same subnet as a currently existing VPN created on the Sonicwall. Since the Sonicwall can't have two VPNs both going to the same subnet, the solution is to use policy NAT on the ASA so that to the Sonicwall, the new VPN appears to have a different subnet.

The current subnet behind the ASA is 192.168.10.0/24 (The Sonicwall already has a VPN created to a different client with that same subnet). I am trying to translate that to 192.168.24.0/24. The peer LAN (behind the Sonicwall) is 10.159.0.0/24. The pertinent configuration of the ASA is:

interface Vlan1

ip address 192.168.10.1 255.255.255.0

access-list outside_1_cryptomap extended permit ip 192.168.24.0 255.255.255.0 10.159.0.0 255.255.255.0

access-list VPN extended permit ip 192.168.10.0 255.255.255.0 10.159.0.0 255.255.255.0

static (inside,outside) 192.168.24.0 access-list VPN

crypto map outside_map 1 match address outside_1_cryptomap

In addition to this, there are other static NAT statements and their associated ACLs that allow certain traffic through the firewall to the server, e.g.:

static (inside,outside) tcp interface smtp SERVER smtp netmask 255.255.255.255

The problem is this: When I enter the static policy NAT statement, I get the message "Warning: real-address conflict with existing static" and then it refers to each of the static NAT statements that translate the outside address to the server. I thought about this, and it seemed to me that the problem was that the policy NAT statement needed to be the first NAT statement (it is last) so that it would be handled first and all traffic destined for the VPN tunnel to the Sonicwall (destination 10.159.0.0/24) would be correctly handled. If I left it as the last statement, then the other static NAT statements would prevent some traffic destined for the 10.159.0.0/24 network from being correctly routed through the VPN.

So I tried first to move my policy NAT statement up in the ASDM GUI. However, moving that statement was not permitted. Then I tried deleting the five static NAT statements that point to the server (one example is above) and then recreating them, hoping that would then move the policy NAT statement to the top. This also failed.

What am I missing?

[Jouni Forss]

Hi,

It would be best if we could see the whole NAT configuration of the device in CLI format to see the current situation.

The ASA in your software wont really let you change the order of the NAT configurations unless it removes some configurations and enters them again.

The most common problem related to the Static NAT and Static Policy NAT is when you have existing Static NAT and then enter new Static Policy NAT configurations. The "static" commands are processed in the order they are configured and therefore sometimes the original Static NAT to a public IP address keeps overriding any new Static Policy NAT.

In this case the usual solution is to first configure the Static Policy NAT and then remove the existing overlapping Static NAT and then enter them again to the configurations which will move them to the end of the "static" configurations.

Can you share your NAT configurations?

If you only use ASDM you can get the CLI format configuration also through that GUI. Go to Tools -> Command Line Interface

This will let you enter the following commands and get the CLI format

show run global

show run nat

show run static

Hope this helps

- Jouni

[mct234]

Thank you Jouni for your patient reply.

Here is the information you requested:

ciscoasa# show run global

global (outside) 1 interface

ciscoasa# show run nat

nat (inside) 1 0.0.0.0 0.0.0.0

ciscoasa# show run static

static (inside,outside) tcp interface smtp SERVER smtp netmask 255.255.255.255

static (inside,outside) tcp interface https SERVER https netmask 255.255.255.255

static (inside,outside) tcp interface 3389 SERVER 3389 netmask 255.255.255.255

static (inside,outside) tcp interface 4125 SERVER 4125 netmask 255.255.255.255

static (inside,outside) tcp interface pop3 SERVER pop3 netmask 255.255.255.255

static (inside,outside) 192.168.24.0  access-list VPN

I had assumed that you are correct and that my static policy NAT statement which appears at the bottom needs to actually be first. So I had entered the following commands using the CLI via telnet:

no static (inside,outside) tcp interface smtp SERVER smtp netmask 255.255.255.255

no static (inside,outside) tcp interface https SERVER https netmask 255.255.255.255

no static (inside,outside) tcp interface 3389 SERVER 3389 netmask 255.255.255.255

no static (inside,outside) tcp interface 4125 SERVER 4125 netmask 255.255.255.255

no static (inside,outside) tcp interface pop3 SERVER pop3 netmask 255.255.255.255

static (inside,outside) tcp interface smtp SERVER smtp netmask 255.255.255.255

static (inside,outside) tcp interface https SERVER https netmask 255.255.255.255

static (inside,outside) tcp interface 3389 SERVER 3389 netmask 255.255.255.255

static (inside,outside) tcp interface 4125 SERVER 4125 netmask 255.255.255.255

static (inside,outside) tcp interface pop3 SERVER pop3 netmask 255.255.255.255

However, as I entered each of the last 5 commands to reenter the static NAT statements, I received the warning message that there was a real-address conflict. When I was finished, my static policy NAT statement was still at the end! I did not bother to save (copy run start) between the first 5 and the last 5 commands, but don't think that matters.

Do you see any problems with my configuration?

[Jouni Forss]

Hi,

I think you will ALWAYS see the warning message simply because some internal IP addresses (SERVER) will now have 2 overlapping "static" configurations in a sense. This warning message is to be expected but it should not prevent normal operation of the NAT.

However the order of the "static" configurations should change to my understanding.

If not then I would suggest removing all of them and entering them with the Static Policy NAT being first and then the Static PAT (Port Forward) configurations.

- Jouni

[mct234]

Journi,

Thanks again for your rapid response. Yes, I tried this again, and this time I also did a "copy run start" after deleting all of the static NAT statements and before reentering them, with the policy NAT statement entered first. However, same result with the policy NAT statement ending up last in the list. Any other ideas of why I can't get that statement to be first?

[Jouni Forss]

Hi,

To be honest it should work in the way I mentioned. I am not sure why it would change the order of the NAT configurations. I have run into this situation on some ASA firewalls running the older software (older than 8.2) and the reordering of the configurations has always worked.

So I am not sure are we looking at some bug or what the problem is.

I was wondering if one solution would be to configure all of the Static NAT / Static PAT as Static Policy NAT/PAT

I have gotten a bit rusty on the older (8.2 and older) NAT configuration format as over 90% of our customer firewalls are running 8.3+ software.

I was thinking of this kind of "static" configuration for the existing Static PAT configurations if you want to try

access-list STATICPAT-SMTP permit tcp host eq smtp any

static (inside,outside) tcp interface smtp access-list STATICPAT-SMTP

access-list STATICPAT-HTTPS permit tcp host eq https any

static (inside,outside) tcp interface https access-list STATICPAT-HTTPS

access-list STATICPAT-RDP permit tcp host eq 3389 any

static (inside,outside) tcp interface 3389 access-list STATICPAT-RDP

access-list STATICPAT-TCP4125 permit tcp host eq 4125 any

static (inside,outside) tcp interface 4125 access-list STATICPAT-TCP4125

access-list STATICPAT-POP3 permit tcp host eq pop3 any

static (inside,outside) tcp interface pop3 access-list STATICPAT-POP3

Naturally you would add the Static Policy NAT for the VPN first.

Again I have to say that I am not 100% sure if this was is the correct format maybe you can test it with a single service that has a Static PAT. For example the Static PAT for RDP (TCP/3389). First entering the Static Policy NAT then removing the Static PAT and then entering the Static Policy PAT.

Remember that you should be able to test the translations with the "packet-tracer" command

For example

packet-tracer input outside tcp 1.1.1.1 12345

- Jouni

[mct234]

Jouni,

How about a different, simpler solution?

What if I just add a static policy PAT statement for each of the 5 ports that are translated to the server? I find that I can indeed move them first before the static NAT statements. For example, for SMTP traffic I add:

     access-list inside_nat_static extended permit tcp host SERVER eq smtp 10.159.0.0 255.255.255.0

     static (inside,outside) tcp 192.168.24.2 smtp access-list inside_nat_static

(Note: 192.168.10.2 is the real address of the SERVER)

Four other access-lists and static policy PAT statements would need to be added to cover the rest of the static NAT statements (3389, 4125, https, and pop3). So the NAT rules would have, in order, the 5 static policy PAT statements followed by the 5 static NAT statements, followed by the static policy NAT statement.

What do you think? Seems like it would work, but is there a simpler way?

[Jouni Forss · Accepted solution]

Hi,

I assumed that we could have changed the order of the "static" commands originally but as it didnt work for some reason then it would seem to me that either the change I suggested or the one you suggested should work.

I guess your aim was to configure Static Policy PAT for the VPN for these certain services and then Static PAT for the access from public network and then Static Policy NAT for the rest of the internal network.

I guess you could choose whichever way seems the best for you.

Let me know if you get it working. I still find it strange that the original configuration didnt work.

Please do remember to mark a reply as the correct answer if it answered your question.

Feel free to ask more if needed

- Jouni