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
22.214.171.124 and 126.96.36.199/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:
188.8.131.52 TCP 80 > 10.10.10.85 TCP 80
184.108.40.206 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 220.127.116.11 are redirected to the internal server 10.10.10.87 but at the same time inbound connections for 18.104.22.168 also arrive at the internal server 10.10.10.87
22.214.171.124 TCP 80 > 10.10.10.87 TCP 80
126.96.36.199 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.
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 (188.8.131.52), and another interface (b) an IP on another subnet (184.108.40.206), the router does not listen on the interfaces for packets on interface (a) for anything that's not on the 220.127.116.11 network. You can send packets on the 18.104.22.168 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 22.214.171.124 can be handled by the NAT tables and translated to 10.10.10.1 if you want, and a packet inbound on 126.96.36.199 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 188.8.131.52 as 184.108.40.206.
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.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...