topic Re: ASA5505 NAT issues. in Network Security

ASA5505 NAT issues.

Brian Korfitz Miehs — Tue, 12 Mar 2019 02:39:39 GMT

I have a site 2 site setup.

(10.10.10.1/24 )Site A <-> Site B (192.168.1.0/24)

On site B I have a webserver and it is being NAT'ted on the outside of Site A this part works like a charm with this nat rule.

nat (outside,outside) source static obj-192.168.1.10 obj-pubilcwebserverip

The reason for this choice lies with where my extra public IP addreses are located.

Now here is the problem.

I want to hide the rest of Site B behind Site A firewall and crated this NAT rule.

nat (outside,outside) source dynamic obj-192.168.1.0 interface

The above rule blocks for access to a mail server on Site A.

This is the config for the mail server on Site A and it's using the outside IP address of Site A for the NAT.

object network EXCHSERVER

nat (inside,outside) static interface service tcp smtp smtp

If i change the blocking NAT rule as shown below everthing is working fine.

nat (any,outside) source dynamic obj-192.168.1.0 interface

1. So why does the outside part block it?

2. Why does it make a difference any or outside?

Fyi. The Site B NAT rule is just above the mail NAT rule since the mail NAT rules is an automatic NAT rule.

Any help will be much appreciated

//Brian

Re: ASA5505 NAT issues.

Jouni Forss — Tue, 17 Sep 2013 09:53:06 GMT

Hi,

I think you are probably running into a problem where the Section 1 Manual NAT for the Site B Dynamic PAT is overriding the Static PAT for the exchange server.

I would suggest changing the Dynamic PAT for the Site B LAN to Section 3 Manual NAT rules by introducing the parameter "after-auto" to the configuration. This Dynamic PAT configuration doesnt need to be at such a high priority

no nat (outside,outside) source dynamic obj-192.168.1.0 interface

nat (outside,outside) after-auto source dynamic obj-192.168.1.0 interface

I am not sure why changing the source interface as "any" has any effect on this situation. But it seems like the order of the NAT rules might be the reason for the initial problem.

This is because an incoming connection to the "interface" IP address with SMTP matches the Manual NAT rule and doesnt even check the SMTP Static PAT configured with Auto NAT in Section 2.

If I was to try determine the reason why the "any" source interface made a different I would have to actually lab this setup and check some outputs from the ASA.

- Jouni

ASA5505 NAT issues.

Brian Korfitz Miehs — Tue, 17 Sep 2013 10:44:41 GMT

Hi Jouni

Thank you for the fast reply

I already solved the initial problem but thank you for the input.

The thing is why two different NAT rules overlap even thou they are about different networks.

Mail NAT rule is regarding a 10.x.x.x network and Site B is 192.168.x.x

//Brian

ASA5505 NAT issues.

Jouni Forss — Tue, 17 Sep 2013 10:58:03 GMT

Hi,

They overlap because of the use of "interface" parameter. In other words you are using the "outside" interface IP address for both the Static PAT and Dynamic PAT

Now when we consider that the Dynamic PAT is in Section 1 above the Static PAT in Section 2 this means that traffic destined to the "outside" interface IP address from the 192.168.1.0/24 network will match the Section 1 Dynamic PAT rather than the Section 2 Static PAT.

The packet arriving on the ASA sees tha the destination IP address is the "outside" interface IP address. It will also see that the traffic is souce from 192.168.1.0/24 and the source interface is also "outside" therefore it matches the Dynamic PAT rule rather than the Static PAT rule.

Lets take a simple example from my home firewall

I for example have the following configurations for testing

object network STATIC-PAT

nat (LAN,WAN) static interface service udp 3389 3389

nat (any,WAN) after-auto source dynamic LAN-NETWORK interface

As you can see, I have a Section 2 Static PAT and Section 3 Dynamic PAT

Now lets look what a "packet-tracer" towards my "WAN" interface IP address on port TCP/3389 would look like

ASA# packet-tracer input WAN tcp 1.1.1.1 12345 x.x.x.x 3389

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network STATIC-PAT

nat (LAN,WAN) static interface service tcp 3389 3389

Additional Information:

NAT divert to egress interface LAN

Untranslate x.x.x.x/3389 to 10.0.0.200/3389

As we can see, the simulated packet would match our Static PAT rule.

Now lets change the setup to be similiar to your problem situation. Lets move my Dynamic PAT from Section 3 to Section 1

object network STATIC-PAT

nat (LAN,WAN) static interface service udp 3389 3389

nat (any,WAN) source dynamic LAN-NETWORK interface

Now lets take the same "packet-tracer" output again.

ASA# packet-tracer input WAN tcp 1.1.1.1 12345 x.x.x.x 3389

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in x.x.x.x 255.255.255.255 identity

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in 0.0.0.0 0.0.0.0 WAN

Phase: 3

Type: NAT

Subtype: per-session

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: WAN

input-status: up

input-line-status: up

output-interface: NP Identity Ifc

output-status: up

output-line-status: up

Action: drop

Drop-reason: (acl-drop) Flow is denied by configured rule

As you can see the simulated packet wont match the Static PAT rule anymore. Granted, the output doesnt really indicate we matched the Dynamic PAT rule but that is what happens. Since the Dynamic PAT rule is matched first the Static PAT will not be applied and the connection fails.

Changing the Dynamic PAT vs. Static PAT order back to the original corrects the situation and everything works as usual

Hope this helps

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

- Jouni

ASA5505 NAT issues.

Brian Korfitz Miehs — Tue, 17 Sep 2013 13:51:44 GMT

It sure did, thank you very much

A bit annoying since i made this error on a customers firewall and this "feature" multiplied my error to wtfpwn level.

//Brian