Simple Port Forwarding on ASA 8.4

[Paul Marks]

All,

I've tried setting up some simple port forwarding on my ASA, where I want to forward one port on the external interface for both UDP and TCP to the same port on an internal server.

It works fine for UDP, but all TCP packets are dropped on the outside interface, even though the configuration for UDP and TCP is basically the same! This is my config:

object network MY_SERVER

host 10.10.1.4

object service TCP_MY_SERVICE

service tcp destination eq 47500

object service UDP_MY_SERVICE

service udp destination eq 47500

nat (OUTSIDE,INSIDE) source static any any destination static interface MY_SERVER service UDP_MY_SERVICE UDP_MY_SERVICE

nat (OUTSIDE,INSIDE) source static any any destination static interface MY_SERVER service TCP_MY_SERVICE TCP_MY_SERVICE

access-list OUTSIDE_IN line 1 extended permit tcp any object MY_SERVER eq 47500

access-list OUTSIDE_IN line 2 extended permit udp any object MY_SERVER eq 47500

access-list OUTSIDE_IN line 3 extended deny ip any any log

Port count goes up on line 2 (UDP) but never for line 1. I just see the packet denied instead. Same thing happens in the packet tracer, a packet destined for my external interface on that port for UDP is allowed and NAT'd just fine. TCP it gets dropped by the ACL on the outside interface.

Where am I going wrong?!

[lcambron]

Hello Paul,

The configuration looks good, I quicky replicated it and it should work just fine.

Can you share the packet tracer output and the exact version you are running?

Regards,

Felipe.

[Paul Marks]

Thanks for your help. Here's the two packet tracer commands - identical except for UDP in the first and TCP in the second:

ASA# packet-tracer input OUTSIDE udp 5.4.3.2 12345 47500

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: UN-NAT
Subtype: dynamic
Result: ALLOW
Config:
object network INSIDE_10.10.1.0
nat (INSIDE,OUTSIDE) dynamic interface
Additional Information:
NAT divert to egress interface INSIDE
Untranslate /47500 to 10.10.1.4/47500

Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE_IN in interface OUTSIDE
access-list OUTSIDE_IN extended permit udp any object MY_SERVER eq 47500
Additional Information:

Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:

Phase: 6
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 7
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network INSIDE_10.10.1.0
nat (INSIDE,OUTSIDE) dynamic interface
Additional Information:

Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:

Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 19145, 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

ASA# packet-tracer input OUTSIDE tcp 5.4.3.2 12345 47500

Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access list

Phase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in      255.255.255.255 identity

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: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

The bit I've just notice there (and wasn't expecting) is in phase 2 of UDP it's matching:

object network INSIDE_10.10.1.0
nat (INSIDE,OUTSIDE) dynamic interface

Which I was using to overload the outside interface for internal users, not for inbound traffic?

ASA# packet-tracer input OUTSIDE udp 5.4.3.2 12345 47500Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access listPhase: 2
Type: UN-NAT
Subtype: dynamic
Result: ALLOW
Config:
object network INSIDE_192.168.1.0
nat (INSIDE,OUTSIDE) dynamic interface
Additional Information:
NAT divert to egress interface INSIDE
Untranslate /47500 to 192.168.1.200/47500Phase: 3
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group OUTSIDE_IN in interface OUTSIDE
access-list OUTSIDE_IN extended permit udp any object MY_SERVER eq 47500
Additional Information:Phase: 4
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:Phase: 5
Type: VPN
Subtype: ipsec-tunnel-flow
Result: ALLOW
Config:
Additional Information:Phase: 6
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:Phase: 7
Type:
Subtype:
Result: ALLOW
Config:
Additional Information:Phase: 8
Type: NAT
Subtype: rpf-check
Result: ALLOW
Config:
object network INSIDE_192.168.1.0
nat (INSIDE,OUTSIDE) dynamic interface
Additional Information:Phase: 9
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:Phase: 10
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 19145, packet dispatched to next moduleResult:
input-interface: OUTSIDE
input-status: up
input-line-status: up
output-interface: INSIDE
output-status: up
output-line-status: up
Action: allowASA# packet-tracer input OUTSIDE tcp 5.4.3.2 12345 47500Phase: 1
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
MAC Access listPhase: 2
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in      255.255.255.255 identityPhase: 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: NP Identity Ifc
output-status: up
output-line-status: up
Action: drop
Drop-reason: (acl-drop) Flow is denied by configured rule

[Paul Marks]

Oh, and version 8.4.3

[lcambron]

Paul,

Looks like the packet is not hitting the NAT rule, now for some reason udp hits the dynamic nat:

object network INSIDE_10.10.1.0

nat (INSIDE,OUTSIDE) dynamic interface

Can you try this NAT rules instead:

object network MY_SERVER

nat (INSIDE,OUTSIDE) static interface service udp 47500 47500

object network MY_SERVER-tcp

host 10.10.1.4

nat (INSIDE,OUTSIDE) static interface service TCP 47500 47500

Run the packet trace again to confirm you are hitting these rules.

Regards,

Felipe.

[Paul Marks]

First - thanks for your help and appologies for the late reply. Bit of a family emergancy here the moment after I submitted the question. Don't think the two are related

Anyway, in answer to your question it looks exactly the same:

ASA#packet-tracer input OUTSIDE udp 1.2.3.4 12345 47500

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: UN-NAT

Subtype: dynamic

Result: ALLOW

Config:

object network INSIDE_10.10.1.0

nat (INSIDE,OUTSIDE) dynamic interface

Additional Information:

NAT divert to egress interface INSIDE

Untranslate /47500 to 10.10.1.4/47500

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group OUTSIDE_IN in interface OUTSIDE

access-list OUTSIDE_IN extended permit udp any object MY_SERVER eq 47500

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type:

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network INSIDE_10.10.1.0

nat (INSIDE,OUTSIDE) dynamic interface

Additional Information:

Phase: 9

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 10

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

New flow created with id 2174850, 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

ASA# packet-tracer input OUTSIDE tcp 1.2.3.4 12345 47500

Phase: 1

Type: ACCESS-LIST

Subtype:

Result: ALLOW

Config:

Implicit Rule

Additional Information:

MAC Access list

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in      255.255.255.255 identity

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: NP Identity Ifc

output-status: up

output-line-status: up

Action: drop

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

So, again, the UDP flow is matching the NAT I created to allow internal clients out (why?!) and the TCP flow matches nothing (why?!)

I thought it was a NAT ordering issue, but then TCP would work correctly, no?

[Julio Carvajal]

Hello Paul,

Do the following to make it work

object network MY_SERVER

host 10.10.1.4

object service TCP_MY_SERVICE

service tcp source eq 47500

object service UDP_MY_SERVICE

service udp source eq 47500

nat (inside,outside) source static  1 MY_SERVER interface service TCP_MY_SERVICE

nat (inside,outside) source static  1 MY_SERVER interface service  UDP_MY_SERVICE

access-list OUTSIDE_IN line 1 extended permit tcp any object MY_SERVER eq 47500

access-list OUTSIDE_IN line 2 extended permit udp any object MY_SERVER eq 47500

access-list OUTSIDE_IN line 3 extended deny ip any any log

Julio

[Paul Marks]

Why source? 47500 is the destination port in the packets I'm looking to NAT, no?

I'll give it a try now though!

[Julio Carvajal]

Hello Paul,

The server is on the inside interface, you want to access from the outside world the internal server on port TCP/UDP 47500.

I will be as simple as the following

In order to set the object service based on source or destination you will need to check the order of the interfaces on the nat you want to do .

In our case

nat (inside,outside) source static  1 MY_SERVER interface service TCP_MY_SERVICE

The object we will try to access it's on the INSIDE, and that is the source interface of our nat so we net to set it as source.

I hope I was clear,

Regards,

Let me know how it goes.

[Paul Marks]

Thanks for your help, and appolgies for my late reply - been manic here. You explanation of source vs. destination makes sense - thanks for that, very clear.

I tried your suggestion and removed the other NAT for the server and added these lines:

nat (INSIDE,OUTSIDE) 1 source static MY_SERVER_UDP interface service UDP_SERVER UDP_SERVER

nat (INSIDE,OUTSIDE) 1 source static MY_SERVER_TCP interface service TCP_SERVER TCP_SERVER

And it worked! The packet trace matched the right rule for both TCP and UDP and both flows were allowed.

I then removed the lines, to try auto-nat again, but it didn't work, so I put these back and... it doesn't work. It works for UDP (packet allowed AND matches this nat rule, not the incorrect one it was matching) but the TCP packet is denied as it always was by the outside ACL.

I am at a total loss. How can that happen!?

[Paul Marks]

Ahah! Almost fixed it!

Right, it was a NAT ordering issue (largely). When I put in these lines:

nat (INSIDE,OUTSIDE) 1 source static MY_SERVER_UDP interface service UDP_SERVER UDP_SERVER

nat (INSIDE,OUTSIDE) 1 source static MY_SERVER_TCP interface service TCP_SERVER TCP_SERVER

I had your "1" there, to control order. When I took them out, I backed them up by typing:

show run | inc nat

And copying pasting the results, which had become:

nat (INSIDE,OUTSIDE) source static MY_SERVER_UDP interface service UDP_SERVER UDP_SERVER

nat (INSIDE,OUTSIDE) source static MY_SERVER_TCP interface service TCP_SERVER TCP_SERVER

Becuase (I assume) the order is dictated on position in the config. I took them out, put them back in with the "1" and it works just fine again!

The remaining mysteries are...

1) Why they had to be at the top? My only other manual NATs where an OUTSIDE to OUTSIDE map to allow VPN users to hairpin back out to the Internet and an INSIDE to OUTSIDE nat that just no-natted an L2L VPN connection.

2) Why, still, doesn't it work as an auto-NAT. It doesn't matter (it works!) but auto-NAT just seems a lot cleaner, no?

3) Why was it matching the auto NAT for internal users that overloaded the external interface at all?

[Jouni Forss · Accepted solution]

Hi,

Can you share you NAT configurations?

This shouldn't be that hard to accomplish.

I for example do a simple PAT + Port Forward scenario with the following configurations.

• Basic PAT 
  • "after-auto" moves the NAT rule to the very end (Section 3)

object-group network PAT-SOURCE

  network-object 192.168.1.0 255.255.255.0

  network-object 192.168.2.0 255.255.255.0

nat (any,outside) after-auto source dynamic PAT-SOURCE interface

• Port Forward

object network PORT-FORWARD

  host 192.168.1.100

  nat (inside,outside) static interface service tcp

EDIT:

If I wanted to add a "NONAT" configuration to the above setup for a L2L VPN I could for example do the following configuration

object network LOCAL-LAN

  subnet 192.168.1.0 255.255.255.0

object network REMOTE-LAN

  subnet 10.10.10.0 255.255.255.0

nat (inside,outside) source static LOCAL-LAN LOCAL-LAN destination static REMOTE-LAN REMOTE-LAN

- Jouni

[Paul Marks]

Here's my current (working) config:

object-group network INSIDE_10.10.1.x

network-object 192.168.1.0 255.255.255.0

nat (INSIDE,OUTSIDE) dynamic interface

nat (INSIDE,OUTSIDE) source static MY_SERVER_UDP interface service MY_SERVICE_UDP MY_SERVICE_UDP

nat (INSIDE,OUTSIDE) source static MY_SERVER_TCP interface service MY_SERVICE_TCP MY_SERVICE_TCP

nat (OUTSIDE,OUTSIDE) source dynamic VPN_USERS_INTERNET_NAT interface

nat (INSIDE,OUTSIDE) source static INSIDE_10.10.1.x INSIDE_10.10.1.x destination static no-proxy-arp route-lookup

The only bit that's new are the MY_SERVER lines for the new NAT'd service on the inside we're offering to the outside. Everything else is old and always worked fine.

It results in this:

ASA# sh nat detail

Manual NAT Policies (Section 1)

1 (INSIDE) to (OUTSIDE) source static MY_SERVER_UDP interface   service MY_SERVICE_UDP MY_SERVICE_UDP

translate_hits = 15686, untranslate_hits = 243488

Source - Origin: 10.10.1.4/32, Translated: /29

Service - Origin: udp source eq 47500 , Translated: udp source eq 47500

2 (INSIDE) to (OUTSIDE) source static MY_SERVER_TCP interface   service MY_SERVICE_TCP MY_SERVICE_TCP

translate_hits = 103, untranslate_hits = 29339

Source - Origin: 10.10.1.4/32, Translated: /29

Service - Origin: tcp source eq 47500 , Translated: tcp source eq 47500

3 (OUTSIDE) to (OUTSIDE) source dynamic VPN_USERS_INTERNET_NAT interface

translate_hits = 0, untranslate_hits = 0

Source - Origin: 10.10.1.190-10.10.1.196, Translated: /29

4 (INSIDE) to (OUTSIDE) source static INSIDE_10.10.1.x INSIDE_10.10.1.x   destination static no-proxy-arp route-lookup

translate_hits = 4, untranslate_hits = 21

Source - Origin: 10.10.1.0/24, Translated: 10.10.1.0/24

Destination - Origin: 192.168.0.0/24, Translated: 192.168.0.0/24

Auto NAT Policies (Section 2)

1 (INSIDE) to (OUTSIDE) source dynamic INSIDE_10.10.1.0 interface

translate_hits = 55051, untranslate_hits = 4303

Source - Origin: 10.10.1.0/24, Translated: /29

What I don't understand is why if I use:

object network MY_SERVER_UDP

  host 10.10.1.4

  nat (INSIDE,OUTSIDE) static interface service udp 47500 47500

object network MY_SERVER_TCP

  host 10.10.1.4

  nat (INSIDE,OUTSIDE) static interface service TCP 47500 47500

It fails with UDP matching the "object-group network INSIDE_10.10.1.x" NAT (so, working, I guess, but not for the reasons I expect) and TCP matches nothing and is dropped by the ACL.

Is it ordering issues again? How do I control the order of auto-nat?

Even if it is ordering, what does UDP match that INSIDE_10.10.1.x NAT anyway?

Cheers!

[Jouni Forss · Accepted solution]

Hi,

I haven't tested the situation but to me it seems the only thing that might cause this is the fact that you have the default PAT configuration at the very top of your NAT configurations. Adding the "after-auto" in the configuration should take it to the very bottom where it would be applied only if no other more specific rules were found. EDIT: Didnt look close enough, seems its not the very top afterall.

Is it possible to redo the whole NAT configuration?

If you decide to try these configurations be sure to backup the current ones incase theres some problems with these.

Looking at your configuration below I would personally try the following (will be using different interface and object names):

Clear NAT configurations

• Clear all NAT configurations from the ASA

Default PAT

• Create Default PAT rule for LAN user Internet traffic  
  • I usually create an object group for the source addresses which makes adding new networks under the PAT that much easier
  • I also usually use the source interface "any" in the NAT statement which means the source network to be NATed/PATed can be behind any interface.

object-group network PAT-SOURCE-NETWORKS

  description Source networks for PAT

  network-object

nat (any,outside) after-auto source dynamic PAT-SOURCE-NETWORKS interface

OR

nat (inside,outside) after-auto source dynamic PAT-SOURCE-NETWORKS interface

Port Forwards

object network PORTFORWARD-UDP47500

  host 10.10.1.4

  nat (inside,outside) static interface service udp 47500 47500

object network PORTFORWARD-TCP47500

  host 10.10.1.4

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

VPN User PAT

• I'm not totally sure but my above PAT configuration with the source interface of "any" might even do the trick with this if you add the VPN source network(s) under the object-group

object-group network VPN-PAT-SOURCE-NETWORKS

  description VPN source networks for PAT

  network-object

nat (outside,outside) source dynamic VPN-PAT-SOURCE-NETWORKS interface

L2L VPN NONAT

• Configure NONAT for the L2L  VPN connection

object-group network L2L-VPN-LOCAL-NETWORKS

  description L2L VPN local networks

  network-object

object-group network L2L-VPN-REMOTE-NETWORKS

  description L2L VPN remote networks

  network-object

nat (inside,outside) source static L2L-VPN-LOCAL-NETWORKS L2L-VPN-LOCAL-NETWORKS destination static L2L-VPN-REMOTE-NETWORKS L2L-VPN-REMOTE-NETWORKS

The above configurations should handle all that you need.

- Jouni

[Julio Carvajal · Accepted solution]

Hello Paul,

Again the most specific at the top, that is all that matters...