Public and private network configuration on ASA 5510

NOTE From The Administrator:
Basic and Advanced ASA5505, 5510, 5520, 5540 Setup and configuration is covered in great depth in an easy-to-follow step-by-step process, at our article below. It is highly recommended our readers read the article as it covers everything presented here with all the necessary explanations and details to ensure no question is left unanswered:

www.firewall.cx/cisco-technical-knowledg...asa5500-startup.html

or simply click on the image below to read our article:





======================================================================
I am having a lot of trouble configuring an ASA 5510 to do what I want it to do. (It's particular frustrating because I can do it with four lines of code in Linux iptables, but we can't use a Linux box as a firewall.)

The goal: Our site needs to have machines on a "public" inside network, where the IP addresses are visible to the outside without any IP address translation. I also want to provide a private "local" network; machines on the local network are NAT'ed to a single IP address when they connect to the outside, but must be individually addressable to machines on the public network, and vice versa.

I've gotten it to this point:

- Machines on the public network can access outside; machines outside can see the public network;

- Machines on the local network can access outside; machines outside see the connection coming from the NAT port;

- Machines on the public network can access the local network ("access" is defined as being able to ssh to them and otherwise have two-way TCP, UDP, and ICMP traffic);

- Here's the sticky part: machines on the private network can ping machines on the public network, and do "steath" port-scans on the public network. But they cannot ssh to them; the returning TCP connections are blocked. UDP connections are apparently fine; the private machines can use DNS servers on the public network.

The firewall has been set up with three interfaces:

outside = IP address 128.XXX.YYY.60
inside = IP address 128.XXX.ZZZ.1; network is 128.XXX.ZZZ.0/24
local = IP address 10.44.0.1; network is 10.44.0.0/16

Security level of the outside interface is 0; security level of both inside and local interfaces are 75. (I've experimented with making the security level of the local interface both higher and lower than the inside interface; it does not affect the problem substantively.)

When I set the syslog warning level on the firewall to "debugger" and ssh from a machine on the local network to a machine on the public network, this is what I see:

Apr 10 19:25:18 gateway %ASA-6-302013: Built outbound TCP connection 3064790 for inside:128.XXX.ZZZ.83/22 (128.XXX.ZZZ.83/22) to local:10.44.10.2/33023 (10.44.10.2/33023)
Apr 10 19:25:18 gateway %ASA-6-302014: Teardown TCP connection 3064790 for inside:128.XXX.ZZZ.83/22 to local:10.44.10.2/33023 duration 0:00:00 bytes 0 TCP Reset-O
Apr 10 19:25:19 gateway %ASA-6-106015: Deny TCP (no connection) from 10.44.10.2/33023 to 128.XXX.ZZZ.83/22 flags RST on interface local

If I try to connect from the public network to the local one, everything is fine:

Apr 11 16:51:51 gateway %ASA-6-302013: Built inbound TCP connection 3655710 for inside:tanya/57779 (128.XXX.ZZZ.83/57779) to local:10.44.10.2/22 (10.44.10.2/22)
Apr 11 16:52:03 gateway %ASA-6-302014: Teardown TCP connection 3655710 for inside:128.XXX.ZZZ.83/57779 to local:10.44.10.2/22 duration 0:00:12 bytes 5527 TCP FINs

Here are what I think are the relevant lines from the firewall configuration, which I created using ADSM:

!!!!!!!!!!!
name 128.XXX.ZZZ.0 PublicNetwork
name 10.44.0.0 LocalNetwork
interface Ethernet0/0
speed 100
duplex full
nameif outside
security-level 0
ip address 128.XXX.YYY.60 255.255.255.248
!
interface Ethernet0/1
nameif inside
security-level 75
ip address 128.XXX.ZZZ.1 255.255.255.0
!
interface Ethernet0/2
nameif local
security-level 75
ip address 10.44.0.1 255.255.0.0
!
same-security-traffic permit inter-interface
access-list local_nat0_outbound extended permit ip LocalNetwork 255.255.0.0 PublicNetwork 255.255.255.0
access-list local_pnat_outbound extended permit ip LocalNetwork 255.255.0.0 any
access-list local_pnat_outbound_V1 extended permit ip LocalNetwork 255.255.0.0 PublicNetwork 255.255.255.0
access-list inside_nat0_outbound extended permit ip PublicNetwork 255.255.255.0 LocalNetwork 255.255.0.0
access-list inside_access_in extended permit ip any any
access-list local_access_in extended permit ip any any
global (outside) 1000 interface
nat (inside) 0 access-list inside_nat0_outbound
nat (local) 0 access-list local_nat0_outbound
nat (local) 1000 LocalNetwork 255.255.0.0
static (inside,outside) PublicNetwork PublicNetwork netmask 255.255.255.0
access-group inside_access_in in interface inside
access-group local_access_in in interface local
!!!!!!!!!!!!

I've RTFMed and googled. I know that "TCP Reset-O" is a sign of packets being denied as they cross security interfaces, but I thought "same-security-traffic permit inter-interface" took care of that. It also doesn't explain the assymmetry: why are packets only blocked in one direction if both interfaces are at the same security level?

I put in the NAT translation exemptions to make sure the packets would be unmodified in both directions. I tried "static (local,inside)" and "static (inside,local)" commands, but the first didn't make any difference... and the second caused my entire network to go haywire for some reason.

Please help! (And thanks in advance.)

After about two weeks of working on the problem, and two hours constructing my elaborate post above, I have a partial answer to my problem:

It wasn't a firewall permissions issue.

What I neglected to mention in my above post is the 128.XXX.ZZZ.83 is a multi-homed host. One of its interfaces was on the public network, and the other on the private. (My intent was to allow our big servers to connect directly to the private network, without going through the ASA 5510 as a router.)

For the first time (*slap myself in the face for waiting too long to try such a simple test*) I tried to ssh from 10.44.10.2 to a non-multi-homed host on the public network... and there were no problems.

I turned off the interface on 128.XXX.ZZZ.83 that connected to the private network... and there was no problem with ssh-ing to the public interface.

A more detailed examination of the firewall log showed this (for a blocked connection):

Apr 11 18:12:47 gateway %ASA-6-302013: Built inbound TCP connection 3693308 for local:10.44.10.2/33048 (10.44.10.2/33048) to inside:128.XXX.YYY.83/22 (128.XXX.YYY.83/22)
Apr 11 18:12:47 gateway %ASA-4-405001: Received ARP request collision from 128.XXX.YYY.1/0030.4876.1e5d on interface inside
Apr 11 18:12:47 gateway %ASA-6-302014: Teardown TCP connection 3693308 for local:10.44.10.2/33048 to inside:128.XXX.YYY.83/22 duration 0:00:00 bytes 0 TCP Reset-O

The reason why the TCP connection is being dropped is because the firewall is getting ARP requests from both ethernet interfaces on the server.

Arrrgh!

So now my question becomes: how do I keep the firewall from dropping the connection just because it gets an ARP request collision?

More research, more RTFMing:

The firewall is doing what it's supposed to do. You want requests from the same IP address, but different MAC addresses, to be rejected because that's a classic IP spoofing attempt.

The problem now becomes: The firewall sees ARP requests from both NICs (and therefore both MAC addresses) on the same network. Somehow, I have to be sure that an ARP requests from the public-network NICs and the private-network NICs don't mix... and I don't know why they're mixing in the first place.

I know this is now outside the scope of this forum. If I find an answer (or if you know of one!), I'll post in here for the sake future people googling on this issue.

After much research, debugging, tcp dumps, arp request tracking, and generally pulling my hair out, I finally have the answer.

First of all, the arp issue I spoke about in my previous post had nothing to do with the problem. There was an "arp flux" problem on my dual-NIC servers:

www.inlab.de/balanceng/faq.html#Q2.09 :

I fixed it using the prescription on the above web page, but it didn't solve my problem.

Once I examine the output of "/sbin/tcpdump" on all the interfaces involved, I found the answer: The machine on the local network sent a TCP packet to the network interface card on the public network. The server thought (if you'll pardon the anthropomorphism), "Aha, I have to send a packet back to a system on the local network, so I'll send it on the network interface card on the local network." The local machine would send request on one network, the server responded on another, and the connection never got made.

After looking at various router and firewall configuration possibilities, I realized that everything was behaving exactly as it was supposed to. If you get an IP packet from an address on network 10.44.x.y, you send it back along the shortest possible route to 10.44.x.y.

I solved the problem by using "split DNS" (although I implemented using a single DNS server). Now, when a user types "ssh myserver", if myserver has two network interfaces, the name 'myserver' resolves to the public network IP on public machines, and to the private network IP on private machines.

Configuring DNS to do this was a little tricky, but it was only a few hours of effort, compared to two weeks of analysis to find out that I'd been an idiot.

C'est la vie!

so basically in the end instead of using public IP address to access your public zone, you used private address?
I thought you public zone only have public IP addresses.
the server sitting in your public zone connected to if 0/2 how does it get to access teh local network? it's on if 0/3?

this problem you are having is because when you trying to access public zone on your local zone, you are going out with the same IP address.
you going out on the outside with 128.XXX.YYY.60
coming in your public which has the same subnet 128.XXX.ZZZ.0/24

for some reason cisco doesn't like when this happen and start dropping the packets.

email me to discuss further...