Another PAT question

JonPertwee · ‎06-10-2010

Hi,

We're having a debate with our hosting provider over what is and isn't posible using PAT on an ASA 5000 series firewall with active failover.

Basically the scenario is that we have a range of host IP addresses, two in particular are of interest

123.45.67.85 and 123.45.67.87/255.255.255.240

These two servers are currently port forwarding port 80 and 443 to two internal webservers

10.10.10.85 and 10.10.10.87/255.255.255.0 which host replica websites.

Inbound connections are as follows:

123.45.67.85 TCP 80 > 10.10.10.85 TCP 80

123.45.67.87 TCP 80 > 10.10.10.87 TCP 80

When one of these webservers goes down for maintenance.. 10.10.10.85 for instance. I want the manager of the firewall to alter the rules so that connections that are arriving at the IP address 123.45.67.85 are redirected to the internal server 10.10.10.87 but at the same time inbound connections for 123.45.67.87 also arrive at the internal server 10.10.10.87

i.e.

123.45.67.85 TCP 80 > 10.10.10.87 TCP 80

123.45.67.87 TCP 80 > 10.10.10.87 TCP 80

Now I think this scenario is perfectly pheasable, I've actually replicated it on a SonicWall device without problem, and I think there is something else driving our hosting provider, but before we ditch them, I want to make absolutely sure that they're wrong. I'm a big boy, if I'm wrong I'll admit it, but I don't think I am.

The reason I've been given that they can't do this is as follows:

"Network engineers at xxxxxx believe the configuration required is not feasible...... This is due to ambiguity on the return packet translated source address with normal TCP/IP stack handling in the firewall. Such function is normally attributed to reverse proxy which can handle such situation termination incoming TCP or UDP session and start the new one towards backend server."

This sounds to me like something brown that comes out of the rear end of a male cow. I was told, when asked why I was able to implement this on a SonicWall firewall that this was because the SonicWall was not a true firewall, and was proxying the sessions, and therefore able to handle it, but the Citrix ASA does not handle TCP packets in such a way.

So please, can someone please tell me if I'm being fed a line here, or is my concept of Networking so far behind the times that I've missed his point?

Either way, please provide me with something I can discuss with my manager.

Thank you everyone.

Federico Coto Fajardo · ‎06-10-2010

Jon,

I think you have posed an excellent question here and I want to tell you this because I've seen this behavior.

You can't have these two rules on the ASA:

123.45.67.85 TCP 80 > 10.10.10.87 TCP 80
123.45.67.87 TCP 80 > 10.10.10.87 TCP 80

There's no problem with the inbound traffic, since the ASA will receive packets on port 80 on both public IPs
and send them to the same internal IP on port 80.

The problem is with outbound traffic.

When the ASA receives packets from 10.10.10.87 on port 80, how will the ASA knows which translation to make?

The ASA won't know if translate this connection to .85 or .87 for the outbound reply.

The above is what I've seen so far...

Federico.

JonPertwee · ‎06-10-2010

Thanks.. You're absolutely right..

Since posting this, I've found this article..

http://itknowledgeexchange.techtarget.com/it-consultant/overlapping-static-nat-and-cisco-asa-firewalls/

Basically we should avoid calling the ASA a firewall, it's not, Cisco were absolutely right in calling it an Adaptive Security Appliance, it acts like a clever switch, not a router.

A fireWALL uses the concept of an inside and an outside, like a wall has two sides, one in and the other out, routing the information between these two based on routing rules. Binding IP addresses to interfaces creates this concept. This is done in Windows and in Linux/Unix. If you have two interfaces on any machine of that ilk, you can give one interface (a) an IP address on one subnet (1.1.1.1), and another interface (b) an IP on another subnet (2.2.2.2), the router does not listen on the interfaces for packets on interface (a) for anything that's not on the 1.1.1.1 network. You can send packets on the 2.2.2.2 subnet to that interface until the wires get hot if you like and they'll just get dropped..

On the other hand, the Cisco ASA acts like a switch. Therefore ALL packets arriving at interface (a) are inspected. If they don't match the rules, they get dropped, if they do, the het handled according to that rule. The reason this is important is that this makes the ASA Adaptive. You can have VLANS and all sorts on these switches, but conceptually, the idea is completely different. Because the interface is largely irrelevant, the rules can be written in either way round, but because of this, you can't have overlapping IP's, for exactly the reason you describe. The transformation on a switch is done in both directions, unlike a router.

We all understand that on a router you can NAT two IP's on the external interface of a router to 1 IP on the internal interface.. This is how failover routers work.. You have two DSL lines for example, and on both you can have inbound mail, return traffic is handled according to the routing tables, if a packet arrived on the 87 IP, return traffic comes back on the 87 IP, if the server on the internal network initiates the connection, the routing of that packet is handled by a completely different set of rules, usually resulting (in the default configuration) with dynamic NAT rules giving it the appearance of the network device itself.

However on a switch, which doesn't have routing tables, we wind up with the problem you describe.. A packet inbound onto 1.2.3.87 can be handled by the NAT tables and translated to 10.10.10.1 if you want, and a packet inbound on 1.2.3.85 can be handled by the NAT tables and translated to 10.10.10.1 if you want. But since the switch has no logical idea of what is inside and outside specifically because IP addresses are not bound to the interface, the NAT tables equally work in reverse, and the NAT tables are ambiguous, 10.10.10.1 can equally be transformed to 1.2.3.85 as 1.2.3.87.

Now, I may have made a few mistakes in what I've written above, I've learned today that an ASA is a switch and not a Router, something I didn't know 4 hours ago (I wish I had!!) and following from that information, I've made a few conceptual leaps in my understanding, so if the information above is incorrect anywhere, I'd appreciate your comments.

Thank you for your input Federico.