ASA 9.x NAT issue

[Saad Mohammad]

So I'm trying to do a simple test in a lab environment but can't seem to understand why the syntax for NAT statements is not working in 9.x. Here is an example:

ASA: outside ip 99.99.99.99/29

     inside ip 192.168.4.1/24

NAT outside ip 99.99.99.100 to inside ip 192.168.4.44 and allow ports https only?

I have done the following:

object network host-192.168.4.44

host 192.168.4.44

nat (inside,outside) static 99.99.99.100 service tcp https https

access-list outside_in extended permit tcp any host 99.99.99.100 eq https

access-group outside_in in interface outside

Packet tracer result:

ciscoasa(config)# packet-tracer input outside tcp 213.23.23.2 https 99.99.99.1$

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 host-192.168.4.44

nat (inside,outside) static 99.99.99.100 service tcp https https

Additional Information:

NAT divert to egress interface inside

Untranslate 99.99.99.100/443 to 192.168.4.44/443

Phase: 3

Type: ACCESS-LIST

Subtype:

Result: DROP

Config:

Implicit Rule

Additional Information:

Result:

input-interface: outside

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

ciscoasa# show nat

Auto NAT Policies (Section 2)

1 (inside) to (outside) source static host-192.168.4.44 99.99.99.100   service tcp https https

    translate_hits = 0, untranslate_hits = 1

ciscoasa# show xlate

1 in use, 1 most used

Flags: D - DNS, i - dynamic, r - portmap, s - static, I - identity, T - twice

TCP PAT from inside:192.168.4.44 443-443 to outside:99.99.99.100 443-443

    flags sr idle 0:03:46 timeout 0:00:00

Let me know if I can try any other syntax or if I put something incorrectly? Thanks

[Jouni Forss · Accepted solution]

Hi,

The NAT configuration is OK even though you are using Static PAT (Port Forward). I would suggest using Static NAT if you can spare the public IP address for this single host. You can then use the ACL to control which ports you allow to this host/server.

Your problem is in the ACL.

The big change in ASA NAT configuration format an operation happened when the 8.3 Software came. From that software upwards the ASA performs the NAT operations first and then checks the ACLs for a destination host.

So in the new software levels this essentially means you will be allowing the traffic to the actual local/real IP address even if this traffic is to be allowed from the external network.

You can actually use the "object" you created for the NAT in the ACL

access-list outside_in extended permit tcp any object host-192.168.4.44 eq 443

I personally tend to name the "object" a bit differently so it clearly mentions the servers role

Hope this helps

- Jouni

[Saad Mohammad]

Thanks for the reply Jouni. I have removed the initial ACL and added the one you provided but am still getting the same drop result. The NAT is taking place, but it's not matching the ACL. Can you lab it up quickly and see the same issue I am seeing? The only way I got forward was when using source static nat ACL. But not sure if I should use that?         

[Jouni Forss]

Hi,

I would have to see the actual configuration to determine what the problem is.

Did you use the "packet-tracer" with the following format

packet-tracer input outside tcp 443

Most typical reasons a "packet-tracer" would fail in a situation where you are configuring a NAT for a server are

• The values used in the command dont match the actual configuration even though the configuration might be completely fine
• The traffic is not allowed to the correct IP address (change in the new NAT operation)
• The interfaces have been configure at the same "security-level" for some reason and this produces an ACL Drop even though no ACL is stopping the traffic.
• There is an overriding NAT configuration that uses the same public IP address as the new Static NAT or Static PAT.

If you can share the configuration (without actual public IP addresses) then I could take a look at it and see what the problem is.

- Jouni

[Saad Mohammad]

Jouni,

I verified the config and the ACL you provided above did show a positive packet tracer result. So does it matter if I use the object for NAT in the ACL or can it be just the IP address of the actual host?

Here was the packet tracer result:

ciscoasa# packet-tracer input outside tcp 213.23.23.2 https 99.99.99.100 https

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network host-192.168.4.44

nat (inside,outside) static 99.99.99.100 service tcp https https

Additional Information:

NAT divert to egress interface inside

Untranslate 99.99.99.100/443 to 192.168.4.44/443

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside_in in interface outside

access-list outside_in extended permit tcp any object host-192.168.4.44 eq https

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network host-192.168.4.44

nat (inside,outside) static 99.99.99.100 service tcp https https

Additional Information:

Phase: 5

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 2, packet dispatched to next module

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside

output-status: up

output-line-status: up

Action: allow

[Jouni Forss]

Hi,

Whether you use the actual IP address in the ACL with the command "host " or the object with the command "object

I guess the main thing is if you configure your Static NAT and Static PAT as Auto NAT / Network Object NAT then you have the ability to use the "object" in the ACL configurations also. The added benefit is if you were to change the local IP address of your server in the "object" configuration used for NAT then naturally this change would update to your ACL with the "object" is referenced. So would no need to confirm the ACL rules in that situation.

Naturally the above situation doesnt happen that often so its has not been that import for me personally atleast so far.

- Jouni

[Saad Mohammad]

Thanks I tested both with the object and just the ip and it works for both.

One more thing, the configuration that I was using was from an 8.2 code and using the same ASA migrated it to 8.3 which migrated these NAT rules. I know a lot of people have said not to rely on the internal migration syntax that ASA does when you upgrade to version 8.3+ but why would the ACLs keep the NATTED host as destination instead of the ACTUAL IP?     

[Jouni Forss]

Hi,

To my understanding it should convert them

Here is a link to a Cisco document here on the CSC that seems to indicate that too

https://supportforums.cisco.com/docs/DOC-12690#ACL_Changes

Personally I have never let the ASA do the migration automatically. I have always done it manually so I know exactly what is configured on the ASA so I can't really tell you any past expiriences about the ASA behaviour when migrating from 8.2 -> 8.3.

Here is a document I wrote about the new NAT format if you want to have a look

https://supportforums.cisco.com/docs/DOC-31116

Here is a link to another great document comparing the old and new formats with examples

https://supportforums.cisco.com/docs/DOC-9129

Naturally you can always post a question here on the forums if there is some questions about the configuration format and operation.

- Jouni