topic Static PAT Access-List bug? (8.3+) in Network Security

Static PAT Access-List bug? (8.3+)

eddie.harmoush — Tue, 12 Mar 2019 02:12:50 GMT

I noticed what appears to be a bug with Access-Lists when using Static Port Translations. Below are the steps to recreate. Was wondering if anyone else has experienced this, or had an idea what was going on. If not, I'll use the forums feature to create a TAC case to confirm it is a bug.

The subject mentions 8.3+ to indicate the new NAT syntax, but the actual Firewall I've been using to recreate this bug are all 8.4(1)+

I have nothing but the following configured on my ASA:

object network WEB-SVR

host 192.168.112.50

nat (inside,outside) static 1.1.99.125

object network +WEB-SVR-ftp

host 192.168.112.50

nat (inside,outside) static 1.1.99.125 service tcp 21 2211

As a test, I create an ACL entry to allow port 80 traffic to my web server:

asa84(config)# access-list 101 extended permit tcp any host 192.168.112.50 eq www

asa84(config)# access-group 101 in interface outside

And using Packet-Tracer, I can verify everything is working as expected, thus far:

asa84(config)# packet-tracer input outside tcp 9.9.9.9 9999 1.1.99.125 80

<~-~-~-~-~ TRUNCATED ~-~-~-~-~>

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group 101 in interface outside

access-list 101 extended permit tcp any host 192.168.112.50 eq www

<~-~-~-~-~ TRUNCATED ~-~-~-~-~>

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

Now I want to allow FTP traffic to my server, but only to the Masked port of 2211. Requests made to my server's IP over port 21 should be blocked. So I create an ACL Entry using the Real port (21):

asa84(config)# access-list 101 extended permit tcp any host 192.168.112.50 eq ftp

And I modify my packet-tracer so packets from the outside are arriving on TCP port 2211:

asa84(config)# packet-tracer input outside tcp 9.9.9.9 9999 1.1.99.125 2211

<~-~-~-~-~ TRUNCATED ~-~-~-~-~>

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group 101 in interface outside

access-list 101 extended permit tcp any host 192.168.112.50 eq ftp

<~-~-~-~-~ TRUNCATED ~-~-~-~-~>

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

So far, all is working as expected. This is where it gets strange. Remember, my goal was to mask my FTP server to a non-standard port. I did not want my server accessed over port 21, only port 2211. However, if a packet-tracer is used to see what happens traffic is sent to port 21:

asa84(config)# packet-tracer input outside tcp 9.9.9.9 9999 1.1.99.125 21

<~-~-~-~-~ TRUNCATED ~-~-~-~-~>

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group 101 in interface outside

access-list 101 extended permit tcp any host 192.168.112.50 eq ftp

<~-~-~-~-~ TRUNCATED ~-~-~-~-~>

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

The same rule which allowed my port 2211 traffic is also incorrectly allowing my port 21 traffic. This appears to be a security risk, in a way, as a port I didn't explicitely allow through my Firewall is being allowed.

If I remove the Static 1-to-1 translation (no object network WEB-SVR), requests on the outside to port 21 are correctly being dropped. But the existence of that Static translation shouldn't affect whether my ACL is processing or dropping traffic, right?

Has anyone else ran into this?

Static PAT Access-List bug? (8.3+)

Jouni Forss — Tue, 16 Jul 2013 17:02:08 GMT

Hi,

As you know, with the new 8.3+ software the NAT is done first and then the ACL. So you will be basically all the time referring to the real IP address and port on the ACL rules.

So for the Static PAT configurations the real port is TCP/21 and that is allowed

In the same way the Static NAT configured contains a TCP/21 to TCP/21 mapping and therefore connection towards the port TCP/21 gets matched to the same ACL after the UN-NAT phase.

To be honest I have never run into this situation myself but now when I look at it, it does seem like there is no real way to differentiate the 2 public ports because the local ports are used in the interface ACL.

I guess one really messy solution would be if the FTP server used a non default local port also.

Then you could block destination port TCP/21 and only allow TCP/2211 in the ACL as it would now be the local port.

Other solution would naturally be to use only Static PAT wihtout the Static NAT configurations.

Cant think of anything else at the moment but will add if something comes to mind.

- Jouni

Static PAT Access-List bug? (8.3+)

julomban — Tue, 16 Jul 2013 17:14:25 GMT

Hello Eddie,

In fact the one-to-one NAT is the one that allows you to connect on port 21:

object network WEB-SVR

host 192.168.112.50

nat (inside,outside) static 1.1.99.125

ASA will check each packet against the NAT table and take the first match, in this case the ASA check for the NAT table and found that there is a one to one translation.

"The same rule which allowed my port 2211 traffic is also incorrectly allowing my port 21 traffic"

Actually is not, the one to one allows port 21 (the same way it took port 80).

What you are seeing is expected, this is the reason why once you removed the one to one it works fine.

Regards,

Juan Lombana

Static PAT Access-List bug? (8.3+)

eddie.harmoush — Tue, 16 Jul 2013 21:21:47 GMT

The issue isn't with the NAT. While I may not entirely agree with it, I understand how the NAT is allowing both the port 21 and port 2211 connection to work.

The problem is with the access-list. With both the Static NAT and the Static PAT in place, there is no way for me to block port 21 traffic, but allow port 2211 traffic. The problem is the same ACL entry that I have in place letting the "wanted" traffic through is also inadvertedly allowing the "unwanted" traffic through.

To me, this seems like a bug =/

Static PAT Access-List bug? (8.3+)

Jouni Forss — Wed, 17 Jul 2013 06:40:41 GMT

Hi,

I would say the NAT and ACL are working in the way they are "supposed" to in the new software.

However, as I said I have never had to configure a setup where I would have both Static NAT and Static PAT configured for the same host.

I do understand your point that this is certainly working in a bad/wierd manner with regards to the ACL. But the fact that the ACLs now refer to the local ports and IP addresses means that the public port isnt referenced in the ACL. Therefore you will be allowing traffic on the port TCP/21 and TCP/2211 since with the Static NAT and Static PAT, both are using the local (unmapped) port of TCP/21 which is the one that the ACL check for.

If I personally ran into this situation I would probably change the configuration so that I would configure Static PAT for all the services that need to be reached through the "outside". If the host/server needed to use the public IP address for outbound traffic I would additionally configure a Dynamic PAT rule using the same public IP address for it.

- Jouni

Static PAT Access-List bug? (8.3+)

julomban — Wed, 17 Jul 2013 15:30:30 GMT

Eddie,

This is not a bug, it is expected, there is no problem with the access list.

If you have both there is no way to block port 21, indeed the same ACL allows both packets but for different flows, one hitting the port forwarding and the other hitting the one to one NAT rule.

Regards,

Juan Lombana

Please rate helpful posts.