1

I have a requirement like this. Please refer the attached image. We have 2 parallel firewall receives traffic from the internet and sends into LAN by NAtting into pvt ips. Both firewall clusters are independent clusters (never shares session) can receive anycast from internet traffic to LAN (I mean it can handle the same IPs from NATTing perspective/policies are synced). However, it connects to same core switch for the LAN.

So now when the traffic goes out, is there any specific ways we can send the response traffic from LAN to the same firewall where it get NATTed, some kind of tags or any ideas we can use to send the traffic to the same firewall for sending it back to internet ? One way is PBR based, but then we have to configure a dedicated IP space for each firewall on the LAN side, is there any easier way to do this like tagenter image description here based routing or something.

|improve this question
  • What you need is a load-balancing decision before routing to either firewall. What is the load balancer supposed to do between firewalls and Internet? What is you goal, high availability or load balancing? – Zac67 Sep 24 '17 at 10:27
  • Even though you load balance 2 clusters, the problem is how it comes back to the same firewall. They are2 independent clusters. – user88975 Sep 24 '17 at 13:17
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could provide and accept your own answer. – Ron Maupin♦ Feb 21 '18 at 14:37
1

You could consider "inside source NAT"-ing this particular incoming traffic into two seperate source NAT address or (better) address pools of private addresses, each implemented by firewall cluster 1, resp. 2. So not only would this traffic be destination NATted when coming in (making the server's private address reachable via a public address), but also source NATted.

Then, from the core switch, route source address pool1 to firewall cluster 1 and source address pool 2 to firewall cluster 2 (possibly with static routes, but eventually, that's up to your internal routing setup).

While technically feasible, there are several important caveats that come with this proposal:

  • the servers on the inside do not get to see the original source address in the IP packets. Be sure to ask the server guys what they think of that.
  • "source NATing the entire Internet" might not be a good idea. Depending on the (size of) client audience these servers have on the internet, your firewall cluster's NAT tables might explode.
  • Be sure to keep IP pool size and NAT translation timeouts timers well tuned. (a single inside source IP can only be used for ~64k simultaneous translations, in this context).
  • Be sure to deeply understand the given application's needs and expectations. [1]

This might not be a great solution (for that, consider running a proper reverse proxy system in a DMZ), but it might work within certain boundaries, and it might work without further infrastructure bits. The "downside" is that you really have to investigate and understand how the application running on the servers actually works.

[1] In extenso: Are these short/long-lived sessions? Is it ok not to see the clients public IP source address? Does the application need to reverse-connect to the client (hope not...)? Is it ok for the client to have completely different TCP session parameters (source IP, source port), when "coming back" after a given amount of time, or does (and if yes, for how long?) the server side application depend on these to re-recognize a given client?

|improve this answer
  • Source NATTing is difficult as the NAtting the entire internet is not good for the firewall additionally we need source ips on the apps. They are all web apps so need the client ps for various purposes at the app level. No reverse originating connection required. – user88975 Sep 24 '17 at 13:20
  • Then I suggest using a dedicated reverse proxy system in a DMZ of each firewall cluster. On both clusters, the public IP should point to the DMZ address of the reverse proxy, and in TCP/IP sense, there will be a "backend" TCP connection towards the webserver - which will be neither source nor destination NATted. That "backend" connection will be from private DMZ IP to private server IP, but since you said it was for web-apps, the reverse proxy can insert the "X-forwarded-for" header into the backend HTTP(S) requests, making the actual client IP available to the web server. – Marc 'netztier' Luethi Sep 24 '17 at 16:32
  • Most webservers are quite happy with the X-forwarder-for HTTP header, and do not actually need the client's IP as source address of the icoming TCP connection. Some firewall vendors do include a reverse proxy feature "in line", so you may not actually need a DMZ and a separate DMZ hosts. With other vendors, the same sometimes be implemented using the "load balancer" feature that works perfectly well if the "set of backend servers" contains only one host and does not actually load balance. – Marc 'netztier' Luethi Sep 24 '17 at 16:36
1

If you map two paths to a single range the information about the path is lost and is hard/impossible to recover.

A relatively easy approach for this is to use two distinct IP ranges for the internal network. Each load balancer maps incoming connections to on of the ranges. Replies source from the IP address the request was sent to and are routed back to the corresponding firewall and load balancer.

If you need hosts serving requests from both load balancers you simply give them IP addresses from both ranges.

|improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.