Problems with the new NAT in ASA 5510 (8.4)

[keksdieb01]

Hi together,

i have some problems with the NAT statements in ASA Version 8.4.

What i want is to translate the internal address of a server to the external address with a NAT rule.

The ASA has only one WAN connection (named outside)

The internal server has the ip address 192.168.0.221 (as example) and i want to translate all incoming traffic on port 3389 to the Server (192.168.0.221).

This is only for training, i dont want to forward a 3389 port into the BAD in a productive Network

first i create the network object for the inside server (192.168.0.221)

object network Network_Obj_RDP

host 192.168.0.221

After that i create the access rule for incoming traffic on outside interface:

access-list outside_access_in extended permit ip any any log debugging

Next i create a access rule for the inside-prod network to allow the traffic to the RDP Server:

access-list inside-prod_access_in extended permit object RDP interface outside object Network_Obj_RDP

Now i create the NAT rule in the network object (Network_Obj_RDP):  

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

But if i want to connect via 3389 on the outside interface i see in the syslog this entry:

Built inbound TCP connection 23248 for outside:80.187.107.132/7445 (80.187.107.132/7445) to inside-prod:192.168.0.221/3389 (External IP/3389)

After a while the connection will be teardown with this message:

Teardown TCP connection 23289 for outside:80.187.107.132/2294 to inside-prod:192.168.0.221/3389 duration 0:00:30 bytes 0 SYN Timeout

It looks like that the acl works fine, but the NAT translation are wrong...

perhaps somebody has a idea to fix this

Looking forward and hope for help...

Many thanks

Greetings

[Jouni Forss · Accepted solution]

Hi,

To me it seems that the Static PAT is configured correctly. Even though the ACL should be configured to only allow TCP/3389 and nothing else.

To me it seems that the connections from "outside" comes to the firewall and is allowed through but the actual local server isnt replying to the connection.

The main reasons for this could be

• Service not enabled on the server
• Software firewall blocking connection
• Server routing isnt correct. The reply from the server isnt forwarded back to where the connection came from
• Some other device in between blocks the connection
• etc

The basic Static PAT configurations format with the new software is

object network SERVER

host 192.168.0.221

nat (inside-prod,outside) static interface service tcp 3389 3389

access-list OUTSIDE-IN permit tcp any object SERVER eq 3389

access-group OUTSIDE-IN in interface outside

EDIT: You dont need an ACL allowing the return traffic from the "inside-prod". ASA is a statefull firewall so it keeps a track of the connections allowed through it and will allow the return traffic from the server back to the user on the Internet. In this case though it just seems that the actual server isnt replying to the connection attempt or its reply is routed to the wrong destination.

Would it be possible that you are configuring some test firewall and since the default route in your local network isnt perhaps pointing towards the "inside-prod" interface of this firewall so the connection attempt from the Internet fails?

I dont see anything wrong with the configuration you mentioned above other than allowing all TCP/UDP traffic from the "outside" but this is for testing purposes I guess.

Hope this helps

- Jouni

[keksdieb01]

Hi Jouni,

thanks for your quick reply, i checked my config and it looks still teh same as yours...

But i do a packet trace, i got a asymmetric  Nat rule message in syslog...

It looks like, that the dynamic NAT is the wrong way back...

They told me in a other forum i should use nat pools to split teh dynamic and the static nat...

Now i am searching for an example for this

But your post was very helpfull and i´m very happy about your fast answer...

greetings and sorry for the bad english

[Jouni Forss]

Hi,

If you can share the NAT configuration I can check it for possible problems

Naturally if you can share the "packet-tracer" output that will help also.

Shouldnt be a hard problem to solve

- Jouni

[keksdieb01]

thanks for your help

here are the output from packet tracer:

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.0.0     255.255.255.0   inside-prod

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside-in in interface outside

access-list outside-in extended permit tcp any object Network_Obj_RDP eq 3389 log debugging

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xad5d5250, priority=13, domain=permit, deny=false

hits=17, user_data=0xaa7ce700, cs_id=0x0, use_real_addr, flags=0x0, protocol=6

src ip/id=0.0.0.0, mask=0.0.0.0, port=0

dst ip/id=192.168.0.220, mask=255.255.255.255, port=3389, dscp=0x0

input_ifc=outside, output_ifc=any

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xad67a1b0, priority=0, domain=inspect-ip-options, deny=true

hits=426, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

input_ifc=outside, output_ifc=any

Phase: 5

Type: VPN

Subtype: ipsec-tunnel-flow

Result: ALLOW

Config:      

Additional Information:

Forward Flow based lookup yields rule:

in  id=0xadcc8ad0, priority=13, domain=ipsec-tunnel-flow, deny=true

hits=21, user_data=0x0, cs_id=0x0, flags=0x0, protocol=0

src ip/id=0.0.0.0, mask=0.0.0.0, port=0

dst ip/id=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

input_ifc=outside, output_ifc=any

Phase: 6

Type: NAT

Subtype: rpf-check

Result: DROP

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

Forward Flow based lookup yields rule:

out id=0xae18b810, priority=6, domain=nat-reverse, deny=false

hits=18, user_data=0xa9377cf8, cs_id=0x0, use_real_addr, flags=0x0, protocol=6

src ip/id=0.0.0.0, mask=0.0.0.0, port=0

dst ip/id=192.168.0.220, mask=255.255.255.255, port=3389, dscp=0x0

input_ifc=outside, output_ifc=inside-prod

Result:      

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside-prod

output-status: up

output-line-status: up

Action: drop

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

[keksdieb01]

and here are the NAT configurations:

sh run nat

nat (inside-prod,outside) source static any any destination static NETWORK_OBJ_192.168.0.96_28 NETWORK_OBJ_192.168.0.96_28 no-proxy-arp route-lookup description VPN

!

object network Network_Obj-Productiv

nat (inside-prod,outside) dynamic interface

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Is it possible that the dynamic NAT rule should be lower than the RDP NAT rule?

greetings

[Jouni Forss · Accepted solution]

Hi,

The 2 Network Object NAT configurations, the Dynamic PAT and Static PAT will be automatically ordered by the ASA when you configure them. So you cant really even modify them at the moment.

I dont see any overlap with the configuration

What I suspect is wrong with the "packet-tracer" command is that you are using the local IP address as the destination address and not the public IP address as you should?

This would cause such a failure in the RPF-CHECK

If you want to check some basic NAT configurations and information about the NAT then check a document I made here on the forums. Maybe it will provide some help with future NAT configurations.

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

- Jouni

[keksdieb01]

Hi Jouni,

this is the correct Packet Tracer output i think:

packet-tracer input inside-prod tcp 192.168.0.220 3389 8.8.8.8 4567

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   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside-prod_access_in in interface inside-prod

access-list inside-prod_access_in extended permit ip object Network_Obj-Productiv any log debugging

Additional Information:

Phase: 4

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 5

Type: NAT

Subtype:

Result: ALLOW

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

Static translate 192.168.0.220/3389 to 80.146.252.162/3389

Phase: 6

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 7

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:      

input-interface: inside-prod

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

That looks preety fine, but the way back isn´t right:

packet-tracer input outside tcp 8.8.8.8 4567 192.168.0.220 3389

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   192.168.0.0     255.255.255.0   inside-prod

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside-in in interface outside

access-list outside-in extended permit tcp any object Network_Obj_RDP eq 3389 log debugging

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: NAT

Subtype: rpf-check

Result: DROP

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

Result:      

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside-prod

output-status: up

output-line-status: up

Action: drop

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

I have no idea...

[Jouni Forss · Accepted solution]

Hi,

If you would like to test traffic that is coming from the Internet towards your server then you can use this format of the "packet-tracer"

packet-tracer input outside tcp 8.8.8.8 12345 3389

Just replace the with the actual public IP address of your "outside" interface that is used for the Static PAT configuration.

The reason why the other direction fails is because you are using the Private/Real IP address of the server as the destination. No host on the Internet will ever connect your servers local/real IP address as they are not routable on the Internet. You will have to use the public IP address.

- Jouni

[keksdieb01]

grml... this day was too long and i totally missunderstood...

new try:

packet-tracer input outside tcp 8.8.8.8 11234 123.456.789.123 3389

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

NAT divert to egress interface inside-prod

Untranslate 123.456.789.123/3389 to 192.168.0.220/3389

Phase: 2

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 3

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group outside-in in interface outside

access-list outside-in extended permit tcp any object Network_Obj_RDP eq 3389 log debugging

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: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

Phase: 7

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 9

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 10    

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: outside

input-status: up

input-line-status: up

output-interface: inside-prod

output-status: up

output-line-status: up

Action: allow

[keksdieb01]

and the way back:

packet-tracer input inside-prod tcp 192.168.0.220 3389 8.8.8.8 123$

Phase: 1

Type: ROUTE-LOOKUP

Subtype: input

Result: ALLOW

Config:

Additional Information:

in   0.0.0.0         0.0.0.0         outside

Phase: 2

Type: ACCESS-LIST

Subtype: log

Result: ALLOW

Config:

access-group inside-prod_access_in in interface inside-prod

access-list inside-prod_access_in extended permit ip object Network_Obj-Productiv any log debugging

Additional Information:

Phase: 3

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 4     

Type: NAT

Subtype:

Result: ALLOW

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

Static translate 192.168.0.220/3389 to 123.456.789.123/3389

Phase: 5

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 6

Type: IP-OPTIONS

Subtype:

Result: ALLOW

Config:

Additional Information:

Phase: 7     

Type: USER-STATISTICS

Subtype: user-statistics

Result: ALLOW

Config:

Additional Information:

Phase: 8

Type: FLOW-CREATION

Subtype:

Result: ALLOW

Config:

Additional Information:

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

Result:

input-interface: inside-prod

input-status: up

input-line-status: up

output-interface: outside

output-status: up

output-line-status: up

Action: allow

[Jouni Forss · Accepted solution]

So as you can see the rules configured on the ASA firewall allow the connection and it also matches the correct NAT rules.

There should be no problem with regards to the ASA for a connection to go through.

Are you testing an actual connection still that doesnt work?

I would start by checking that the actual server has a route towards this ASA for the host that is attempting the connection through the ASA.

- Jouni

[keksdieb01]

The server (192.168.0.220) has a internet connection trough this firewall and it still works...

But on the Firewall on the server i didnt see any connection on port 3389 (exempt my local connection via workstation).

it is a wired and my head starts smoking

[Jouni Forss · Accepted solution]

And one note,

You dont have to test the return direction of the traffic. A connection that has already been allowed through the firewall will never be matched against your ASAs internal interfaces interface ACL.

Also the "packet-tracer" that is run to simulate the connection coming from the Internet already tells you if the NAT configurations on your ASA are ok for both the inbound and outbound direction.

Phase: 1

Type: UN-NAT

Subtype: static

Result: ALLOW

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

NAT divert to egress interface inside-prod

Untranslate 123.456.789.123/3389 to 192.168.0.220/3389

The above Phase tells us that a NAT rule was matched and the packet was diverted to the interface "inside-prod" after the public NAT IP address was UN-NATed to the local IP address

Phase: 6

Type: NAT

Subtype: rpf-check

Result: ALLOW

Config:

object network Network_Obj_RDP

nat (inside-prod,outside) static interface service tcp 3389 3389

Additional Information:

The above Phase tells us that the Reverse Path is fine also as it matches the same NAT configuration that for the inbound traffic from the Internet.

- Jouni

[keksdieb01]

hmm... so i dont understand why it dosn´t work

Thanks for your patience, it is very helpfull