NAT Address range different to Public

[Mark Cavendish]

Hi

We have a new ASA box in place with a Private, DMZ and Public card which routes out to the Internet fine and everything is currently working as it should.

I am trying to setup the NAT part, yet the range we have been given is on a different subnet to the Public one we have configured.

Could anyone tell me the procedure to get it to work?

I understand setting up a static NAT rule to map the Public to Private and allowing the access rules to connect. Yet I am confused on how to setup routing to this new subnet, I thought I could configure a loopback, but this isn't allowed I understand on the ASA. Any example configs would be much appreciated.

Many thanks in advance,

Mark

[Eugene Korneychuk]

Hi Mark,

Your ISP will route the new route to your link. You do not need to assign the new IP to any interface. You can create statics using the new address space and it will work because of the ISP sending the route down to you.

Please rate helpfull posts

[Mark Cavendish]

Hi Eugene

I knew it had to be something straight forward and I was over complicating matters. I can now actually see traffic for that subnet being forwarded in the real time log viewer.

So I have created a static NAT rule:

Public Interface

Source IP address (Public Nat one)

to

Translated Interface

Private Interface

Private IP address

I have also created 2 incoming Public access rules allowing HTTP & HTTPS to the private IP address to test it. Yet I am getting a 'bad request (invalid hostname)' message in an outside IE' and the ports are still showing filtered on a external Nmap scan on those 2 ports.

Am I missing something else?

Thanks again,

Mark

[Eugene Korneychuk]

Hi Mark,

You need a static nat rule, and access-list which will permit this host,

Before 8.3 to public ip, after 8.3 it to real ip.

You can emulate traffic with packet-tracer, also you can make captures on outside interface to check, if this traffic reaching the ASA.

Thank you.

[Mark Cavendish]

Hi Eugene

This still isn't working for me unfortunately and I don't know where I am going wrong, I really appreciate your help so far. I am on 8.2 and this is just a test to get it working before we map Public to DMZ.

Here is the config I have:

NAT

static (Private,Public) 193.172.195.2 10.25.1.1 netmask 255.255.255.255

#sh xlate

Global 193.172.195.2 Local 10.25.1.1

So NAT seems to be working.

Access Rules

I have the following access rule:

access-list PUBLIC-ACL extended permit tcp any host 193.172.195.2 eq www

Yet when I do a packet trace on the exception rule, I get:

Packet Trace

Interface: Public
Source IP: 93.13.216.93         Destination Address: 193.172.195.2
Source Port : 1065                 Destination Port: 80

+UN-NAT
-Type - Un-NAT | Subtype - Static | Action - Allow | Show rule in NAT Rules table.

Config
static (Private, Public) 193.172.195.2 10.25.1.1 netmask 255.255.255.255
match ip Private host 10.25.1.1 Public any
static translation to 193.172.195.2
translate_hits=3, untranslate hits=111

Info
NAT divert to egress interface Private
untranslate 193.172.195.2 to 10.25.1.1/0 using netmask 255.255.255.255

(GREEN TICK)

+ACCESS-LIST
-Type-ACCESS-LIST | Action - ALLOW | Show rule in Access Rules table.

Config
access-group PUBLIC-ACL in interface Public
access-list PUBLIC-ACL extended permit tcp any host 193.172.195.5 eq www

(GREEN TICK)

+IP-OPTIONS
-Type - ACCESS-LIST | Action - DROP

(GREEN TICK)

+ACCESS-LIST
-Type-ACCESS-LIST | Action - ALLOW | Show rule in Access Rules table.

Config
Implicit Rule

(Red Cross)

+RESULT - The packet is dropped.
Input Interface: Public              Line Up     Link Up
Output Interface: Private          Line Up     Link Up
Info: (acl-drop) Flow is denied by configured rule

(Red Cross)

It is being denied by the implicit any to any Public access default incoming rule, even though I have the exception listed above it,

Regards,

Mark

[Mark Cavendish]

I also noticed this message in the logs when I try to telnet to Port 80:

4     Dec 04 2012     12:52:23     106023     93.13.216.93     38255     193.172.195.2     80     Deny tcp src Public:93.13.216.93/38255 dst Private:193.172.195.2/80 by access-group "Private_access_out" [0x0, 0x0]

[Jouni Forss]

Hi,

Do you have another access-list attached to the interface "Private" in the direction "out" ? If this is true it would pass the Public interfaces ACL but hit the ACL on the Private interface thats attached to direction "out"

This would mean having the following configuration

access-group Private_access_out out interface Private

You can check it by using the command "show run access-group"

- Jouni

[Mark Cavendish]

Hi Jouni

I do have a access list for Private outbound for Proxy and NTP to Servers etc:

#show run access-group

access-group Private_access_out out interface Private

access-group Public_access_in in interface Public

So my problem is this access list denying my Private host from going back out of the public interface to complete the session from initiating an outbound connection?

Thanks again,

Mark

[Mark Cavendish]

Hi

I have now added a access rule from Private_access_out  for source any to 10.25.1.1 and it seems to be building the connection,  but it doesn't complete.

6    Dec 04  2012    15:57:34    302014    93.13.216.93    53559    10.25.1.1     80    Teardown TCP connection 2210 for Public:93.13.216.93/53559 to  Private:10.25.1.1/80 duration 0:00:30 bytes 0 SYN Timeout

6     Dec 04 2012    15:57:17    302013    93.13.216.93    53560     10.25.1.1    80    Built inbound TCP connection 2211 for  Public:93.13.216.93/53560 (93.13.216.93/53560) to Private:10.25.1.1/80  (193.172.195.2/80)

My access rules for info are:

access-list Private_access_in extended permit ip any any

access-list Public_access_in extended permit tcp any host 193.172.195.2 eq www

access-list public extended permit ip any any

access-list OUT extended permit ip host 10.25.1.9 any

access-list Private_access_out extended permit object-group TCPUDP host 10.25.1.8 interface Public eq www

access-list Private_access_out extended permit icmp host 10.25.1.8 interface Public

access-list Private_access_out extended permit tcp host 10.25.1.8 interface Public eq https

access-list Private_access_out extended permit object-group TCPUDP host 10.25.1.8 any eq domain

access-list Private_access_out extended permit icmp host 10.25.1.8 interface Public traceroute

access-list Private_access_out extended permit ip host 10.25.1.8 interface Public

access-list Private_access_out extended permit object-group TCPUDP host 10.25.1.8 interface Public

access-list Private_access_out extended permit tcp host 10.25.1.8 interface Public eq ftp-data

access-list Private_access_out remark FSBGS1 Timesync to external NTP clock.

access-list Private_access_out extended permit object-group TCPUDP host 10.25.1.1 host 84.170.75.28 object-group NTP-tcp

access-list Private_access_out extended permit tcp any host 10.25.1.1

access-list Private_access_out extended permit tcp host 193.172.195.2 any

Thanks again for all the help so far,

Mark

[Jouni Forss · Accepted solution]

Hi,

My first reply was simply from the basis of the packet-tracer ouput. I tried to read the earlier posts now.

Is the IP address/host 10.25.1.1 on the local LAN network? I'm so used to using .1 always for the default gateway IP address (= ASAs interface IP) that it looks wierd to me.

Simply put the logs just state that the connections has been formed through the ASA but is tore down after 30 seconds since the destination host hasnt replied to the initial SYN from the outside host.

Usually this is because

• Software firewall blocking the connection on the server
• Wrong default gateway on the server
• Service not enabled on the server (FTP, Web or whatever you might be using)
• There is some other routing problem regarding the return traffic (usually a bigger network)

Easiest way to troubleshoot this would be to get the actual ASA configuration minus any sensitive information. Also information about what is the local IP of the server and what is the public IP address reserved for the host.

- Jouni

[Jouni Forss]

Also,

I would personally suggest using the "in" direction when configuring ACLs. If you now forexample have an access-list on the "outside" interface in the direction "in" and an ACL on the "inside" interface in the direction "out", all traffic from the public networks will have to be checked against 2 ACLs instead of the usual 1.

Also regarding the use of ACLs on the ASA. When ASA has allowed a connection through one of its interfaces, the return traffic wont have to be allowed anymore. ASA will automatically allow the return/reply traffic of the same connection through the firewall.

And again, if you want to provide some basic information or the current configuration of the ASA, we can go through some of the configurations if they need clearing up or something needs to be modified.

- Jouni

[Mark Cavendish]

Hi Jouni

It was as simple as no route from this Server on the inside back out to the Internet through this ASA box. It had a default gateway which goes out to the Internet at our other site as it hasn't been amended yet. As soon as I put a static route in - problem solved.

So thank you to you and Eugene for all your help. All the original troubleshooting above helped me get to this as there was access rule problems and I am now a lot more familiar with the procedures and troubleshooting having limited exposure to the ASA.

Mark