ASA_Static_NAT

[Stephen Sisson]

Hello,

I'm working with the 5505 ASA firewall to create a static NAT to allow RDP 3389 access into our network from the outside.

My problem while in ASDM version 7.0 we choose configuration then NAT rules then click on Add but all we see is Add NAT rules before network object NAT rule, Add network object to NAT rule, and NAT rule after network object NAT rule.

I'm not sure why we see only the three options and no Static Nat rules.

Can anyone help to resolve this issue or explain what's going on.

Thank you

[Jouni Forss]

Hi,

This is because of the new software and the related NAT configuration changes.

Do you have a spare public IP address for this server OR are you going to use the "outside" interface IP address and Port Forwarding?

You can use either of the following configurations

Static NAT

• Using a spare public IP address

object network SERVER

host x.x.x.x

nat (inside,outside) static y.y.y.y

access-list permit tcp any object SERVER eq 3389

Static PAT (Port Forward)

• Using the "outside" interface IP address of the ASA
  

object network SERVER-RDP

host x.x.x.x

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

access-list permit tcp any object SERVER-RDP eq 3389

Where

• x.x.x.x = Is the real IP address of the host/server
• y.y.y.y = Is the spare public IP address for this host/server

On the ASDM side you would configure this for example with choosing "Network Object NAT"

You can drop either of the 2 configuration, depending on which you want (not both at the same time), by copy/paste the object/NAT configuration and going in the ASDM to

Tools -> Command Line Interface -> Chose Multiple Lines -> Insert configurations

Naturally we can look through your configurations and confirm that this is done correctly.

- Jouni

[Stephen Sisson]

Hello Jouni, thanks for working with me again.

I'm having some issues with the Globalscape FTP server and thought to test outside access into the same server we configured for FTP to allow RDP 3389 to test connections from the outside.

I was reading some of the Cisco documents for adding RDP 3389 that shows the adding static NAT and when we checked no static NAT - never thought about the version changing this option - thank GOD for your help.

Let me explain the FTP issue - we created the NAT rule / Access Rules to allow FTP-21,TCP-443, TCP-80, TCP-990, TCP989, TCP-22 to allow outside access to the Globalscape Gateway server, then allowed inside gateway server out on TCP-989, TCP-443, TCP-80 , TCP-22, TCP-FTP-Data.

I also used the Packet tracer to confirm outside public address can access the Globalscape Gateway server on each port listed above from the outside, then reversed this to confirm inside has access outside. We still have reports that no one can connect to the Globalscape Gateway server.

The way this works is users on the internet make a request to our FTP server with public IP address that is then sent to our Globalscape Gateway server, then the Globalscape Server makes the connection to the inside EFT FTP server, allowing the file transfer.

I'm willing to send you the running-config if needed.

I hope this helps to understand how things work and what we have put in place.

Thank you Sir

[Jouni Forss]

Hi,

If you want to first test the original thing of connecting to the server with TCP/3389 then it should be pretty straightforward.

So you already have a Static NAT configured for the server correct?

Can you post that NAT configuration in CLI format. Something like this

object network

host x.x.x.x

nat (source,destination) static y.y.y.y

I would imagine that the ASA can easily handle the FTP connection formed from "outside". The configuration "inspect ftp" is good to have on for the ASA to be able to automatically allow the Data connections of FTP after the Control connection has first been formed.

My doubt in this case would be with the thing that is happening in your LAN.

I'm not quite sure how the setup works if the user first connects from "outside" to your server by FTP and there is also a FTP connection from that server somewhere else on the LAN?

- Jouni

[Stephen Sisson]

Hello,

I completed the new NAT / ACL for the RDP 3389 and this works from the outside to the Globalscape gateway server.

I'm not sure about the LAN,

Let me ask a few more question to see if I understand the NAT/ACL on the ASA.

We have outside users who need access to our internal FTP server and they get there by the Globalscape Gateway server, we have several ports to open for allowing this access, we create ACL's for each port that needs opening for outside to inside and vise verse for inside out. We then are required to add a NAT rule for each port we allowed in the ACL, or one NAT rule. The reason I ask is with the remote access RDP-3389 we created the ACL, one NAT rule to allow outside access to the server and this worked.

Thank you

[Stephen Sisson]

I'm sorry - the NAT information as requested

Auto NAT Policies (Section 2)
1 (outside) to (PCSFTP) source static Remote_Access_RDP3389 98.101.206.51
    translate_hits = 0, untranslate_hits = 0
2 (PCSFTP) to (outside) source static obj-172.16.5.2 98.101.206.51
    translate_hits = 188, untranslate_hits = 4907
3 (PCSFTP) to (outside) source static SERVER 98.101.206.52
    translate_hits = 352, untranslate_hits = 2170
4 (PCSFTP) to (outside) source dynamic obj_any interface
    translate_hits = 148, untranslate_hits = 6

Manual NAT Policies (Section 3)
1 (inside) to (outside) source dynamic any interface   description PAT_Inside_Outside_on_MPLS_Circuit
    translate_hits = 9, untranslate_hits = 0

[Jouni Forss]

Hi,

Can you instead of the above provide the out of "show run nat"

And possibly the following too

sh run object id Remote_Access_RDP3389

sh run object id obj-172.16.5.2

sh run object id SERVER

The first rule in the above posted output seems a bit off to me. It also doesnt have any hits so far.

- Jouni

[Stephen Sisson]

Yes Sir

show run nat

!

object network obj_any

nat (PCSFTP,outside) dynamic interface

object network obj-172.16.5.2

nat (PCSFTP,outside) static 98.101.206.51

object network SERVER

nat (PCSFTP,outside) static 98.101.206.52

object network Remote_Access_RDP3389

nat (outside,PCSFTP) static 98.101.206.51

!

nat (inside,outside) after-auto source dynamic any interface description PAT_Inside_Outside_on_MPLS_Circuit

PCSASAFW# sh run object id Remote_Access_RDP3389

object network Remote_Access_RDP3389

host 172.16.5.2

description Allow outside remote access to ftp server

PCSASAFW# sh run object id obj-172.16.5.2

object network obj-172.16.5.2

host 172.16.5.2

PCSASAFW# sh run object id SERVER

object network SERVER

host 172.16.5.5

description PCS_L2TP_PPTP_Remote_VPN

show run nat
!
object network obj_any
nat (PCSFTP,outside) dynamic interface
object network obj-172.16.5.2
nat (PCSFTP,outside) static 98.101.206.51
object network SERVER
nat (PCSFTP,outside) static 98.101.206.52
object network Remote_Access_RDP3389
nat (outside,PCSFTP) static 98.101.206.51
!
nat (inside,outside) after-auto source dynamic any interface description PAT_Inside_Outside_on_MPLS_Circuit

PCSASAFW# sh run object id Remote_Access_RDP3389
object network Remote_Access_RDP3389
host 172.16.5.2
description Allow outside remote access to ftp server

PCSASAFW# sh run object id obj-172.16.5.2
object network obj-172.16.5.2
host 172.16.5.2

PCSASAFW# sh run object id SERVER
object network SERVER
host 172.16.5.5
description PCS_L2TP_PPTP_Remote_VPN

[Jouni Forss]

Hi,

So below should be your NAT configurations for Static NAT

object network obj-172.16.5.2

host 172.16.5.2

nat (PCSFTP,outside) static 98.101.206.51

object network SERVER

host 172.16.5.5

nat (PCSFTP,outside) static 98.101.206.52

The BOLD GREEN NAT rules are the ones I think we have been looking at before and they should be working ok.

object network Remote_Access_RDP3389

host 172.16.5.2

nat (outside,PCSFTP) static 98.101.206.51

The above BOLD RED NAT however doesnt seem like something you will need.

What the above NAT basically says to the ASA is that

• You have a host 172.16.5.2 behind the "outside" interface on the ASA
• That host should be NATed to 98.101.206.51 towards the network behind the interface "PCSFTP"

I dont see any need for this kind of configuration cause naturally the host 172.16.5.2 is not behind the "outside" interface.

The 2 working NAT configuration at the very start that I mentioned should be working fine though. Notice that those NATs apply whatever the direction was.

In other words

• When host 172.16.5.2 connects to some host behind "outside" it will be visible with the public IP address 98.101.206.51
• When any host on the public network behind the "outside" interface want to connect to host 172.16.5.2, they will connect to the public IP address of 98.101.206.51

So you wont need to do any more NAT configurations for these LAN hosts, towards the public networks behind "outside" atleast. If you want to open new services to them from "outside" you naturally need to make additional ACL rules but no NAT rules.

As we have confirmed that the original 2 NAT rules work and the TCP/3389 connection goes through then we need to clear up what is wrong with the FTP connection?

To my understanding any host behind "outside" should already be able to connect to the server with FTP at the moment? Is this true or dont the FTP Control connections form to the server (TCP/21)?

- Jouni

[Stephen Sisson]

Jouni,

Let me see if I understand - no need for additional NAT rules for the FTP remote access or for the remote PPTP/L2TP they are covered by the current NAT rules.

I still have the problem with users on the outside connecting to our FTP server - think the ASA NAT is causing the problem, posted on the Globalscape website that firewall NATTING can cause connection issues, is there any way around this or should we look at something else causing this issue.

Thank you Sir

[Jouni Forss]

Hi,

Dont think I have run into an FTP connection that didnt work through an ASA firewall. Usually the problem has been with the actual FTP endpoints rather than the firewall.

Can the users from "outside" even form the Control connection to your server or does the connection attempt simply timeout or something?

Can you post the output of "sh run policy-map"

With regards to the NAT rules.

Since you have configured the following NAT configurations

object network obj-172.16.5.2

host 172.16.5.2

nat (PCSFTP,outside) static 98.101.206.51

object network SERVER

host 172.16.5.5

nat (PCSFTP,outside) static 98.101.206.52

It pairs the local 172.16.5.x IP addresses with their own public IP addresses. After this is done they dont need any altering to work for different services. You just use ACLs to allow whatever traffic you want allow to them from the public network.

The only situation where you need to configure a new NAT configuration every time a new service needs to be allowed is when you are using Port Forward NAT configurations. This is usually done when you only have 1 public IP addresses and still want to enable accessing LAN hosts using that single IP address.

You will only need Port Forward NAT configurations when you run out of spare public IP addresses. And at the moment you have a separate public IP address for each of your 2 servers so there should be no problems with regards to NAT at this point for servers.

- Jouni

[Stephen Sisson]

Yes Sir

show ru policy-map

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum client auto

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

inspect ip-options

inspect pptp

inspect icmp

inspect icmp error

show ru policy-map

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum client auto

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

inspect ip-options

inspect pptp

inspect icmp

inspect icmp error

show ru policy-map

!

policy-map type inspect dns preset_dns_map

parameters

message-length maximum client auto

message-length maximum 512

policy-map global_policy

class inspection_default

inspect dns preset_dns_map

inspect ftp

inspect h323 h225

inspect h323 ras

inspect rsh

inspect rtsp

inspect esmtp

inspect sqlnet

inspect skinny

inspect sunrpc

inspect xdmcp

inspect sip

inspect netbios

inspect tftp

inspect ip-options

inspect pptp

inspect icmp

inspect icmp error

The outside users try to connect to the FTP server and we see this in the ASA as built inbound, then we see teardown but no true connection from outside to the Globalscape Gateway server to the internal EFT FTP server.

I'm not sure why - we have proved the ASA is setup correctly and traffic is getting to the firewall / Server.

Thanks for the explanation for the NAT and when to create new rules / ACL's, so kind to help me understand how things work. May I ask about training - what would you recommend.

Thank you

[Jouni Forss]

Hi,

What is the Teardown reason mentioned at the end of the log message when the FTP connection is removed from the ASA?

I dont still understand what is the deal with the fact that a user would connect with FTP to your server which would then again connect to some other server with FTP? Shouldnt the "outside" user connect directly to the FTP server they need and not use some other server?

I'm not quite sure why the setup would have 1x Client and 2x FTP server.

With regards to the training I can't really comment much. I've only taken a couple of simple ASA courses through my employer. But to be honest just configuring firewalls in my work teaches me a lot more than courses. The problem with courses is that they try to pack way too much content into them in too short of a timeframe and you end up learning very little about each subject.

Problem situations (like faced here on the forums) and actual configuration practice and testing have been the best way to learn for me.

- Jouni

[Stephen Sisson]

Hi

The reasoning my Boss has is to protect the internal FTP server from the outside by adding the Globalscape Gateway server as the person or server who handles the connection from the outside to the internal EFT FTP server.

The Globalscape server has two network cards, the internal EFT FTP server has two network cards, with one interface both the Globalscape Gateway and the EFT FTP server on the same internal subnet and showing the connection between them.

The only thing not working is the outside connection to the Globalscape server and this server connecting to the EFT FTP on one of several ports referenced in our original replay above.

The connection then teardown log looks like this.

6 Feb 26 2013 13:59:07  209.177.212.6 6284 172.16.5.2 21 Built inbound TCP connection 9946 for outside:209.177.212.6/6284 (209.177.212.6/6284) to PCSFTP:172.16.5.2/21 (98.101.206.51/21)

6 Feb 26 2013 13:59:37  209.177.212.6 6284 172.16.5.2 21 Teardown TCP connection 9946 for outside:209.177.212.6/6284 to PCSFTP:172.16.5.2/21 duration 0:00:30 bytes 0 SYN Timeout

From what I see the Globalscape server is failing to do the job for allowing the outside connection to this server, the Globalscape server then connection to the internal EFT FTP for file transfers..

[Jouni Forss]

Hi,

I dread environments with hosts/servers with several network cards.

What the above logs tells us is that the "outside" host has no problem of connecting towards the host 172.16.5.2 through the Internet (ofcourse using the public NAT IP address)

The TCP connection doesnt form however. The reason for this is simply that the server 172.16.5.2 doesnt reply to the TCP connectiong forming at all. This is why the connection gets removed by the ASA after 30 seconds with the message SYN timeout.

And for this there could be several reasons

• The server might be blocking the connection
• The server might not be listening on that port on the specified interface
• The server having 2 interfaces itself might be routing the reply to the TCP SYN message from "outside" through the wrong network interface. Even if this reply reached the ASA the ASA would block this connection as the reply would be coming from the wrong IP address (not coming from the 172.16.5.2 but the IP address of the other network interface the server has)
  • Naturally if this other interface is only connected to the other device, the return traffic wouldnt reach the ASA but would still be lost because it got forwarded through the wrong interface.

If the server that the "outside" hosts are connecting to is a Windows server? then you can check its routing from the command prompt with "route print" to see which interface has the default route.

Could it be possible that when the "outside" user is connecting to the server that the server sends all the return traffic through the wrong network interface which is actual connected to the other system (and not the ASA).

- Jouni