Source and Destination NAT on firewalls

Archived from groups: comp.security.firewalls (More info?)

Hi,

I have what I believe must be a common setup and I'd like to find out
how other people make this work. I can see one way, but it's far from
optimal.

Okay, we have two sites, with an internet connection to each and a
firewall on each of the connections. Internally, there is one network,
with one connection "at each end". Our hosts sit on the internal
network. (OK, it's a DMZ, but let's not get picky). Externally, our
ISP provides a DNS service which can have two IP addresses for each
host, which are delivered to clients on a round-robin basis. The first
IP address points to the first firewall and the second one points to
the second firewall. Nothing too fancy so far.

However, there is no will to throw much money at this particular
setup, so the firewalls are independant of each other and don't load
share or anything fancy like that. So, the above setup only functions
partly as I would like.

In short, each internal host can only communicate with one firewall at
a time, by virtue of it's default route to the outside world. That
means that it will fail to return any packets for a session
established by the firewall with which it cannot communicate. So an
external client only has a 50/50 chance of sending to an IP address
that works. When they send to the 'wrong' one, the browser will
recover and try the second, but there is a delay.

With me so far ? Okay...

I thought that this setup would work fully because I believed that the
host would simply send return packets to the firewall through which
the session had been established, no matter what its default route
said. I believed that it would work like this...

DNS www.example.com: 5.6.7.8

Client IP 1.2.3.4

Client Packet
Source Destination
1.2.3.4 5.6.7.8

Firewall external IP 5.6.7.8
Firewall internal IP 9.10.11.12

Firewalled Packet
Source Destination
9.10.11.12 13.14.15.16

Host IP
13.14.15.16

Those who are following so far (Wake up at the back !) may realise
that my Firewalled Packet is wrong. Only the Destination address gets
translated and the Source stays the same. (This may be a feature of
the particular firewall we have, but I've checked with tcpdump and
this is really what's happening.) So, unless the host holds a route
for the client AND that route matches with the route that the session
was established on, then it can't return any traffic to the client.

I'm not familiar with hardware firewalls, so I'm not sure if this is
normal behaviour. I've had a quick read and it certainly seems to be
normal for this one, but I'd appreciate the benefit of someone else's
experience. It's NOT a top-of-the-range firewall, by the way.

Okay, if you're still following - unless I can make the firewall
behave differently, or get a better firewall, how do I get out of this
?

One solution is to stick two firewalls back-to-back on each
connection. As packets pass through, one firewall will translate the
Source address, the other will translate the Destination address. The
host will believe it is communicating with the firewall alone and will
talk to it happily on the internal subnet. (Yes, they are both on the
same subnet.) However, this seems a bit wasteful of firewalls and not
a very elegant solution.

I'm sure I can't be the first person to face this problem, so "answers
on an email, please" !

Regards,
Martin.