2 firewalls 1 Internet connection

I would like to do the following, and want to know if anyone out there can identify any potential pitfalls of this configuration. (for the record, I think this wil NOT work).

I want to use 2 different hardware firewalls over the same Internet connection. Specifically, I want to run a PIX 506 (that has a VPN tunnel with our Mexico operation) and I want to run a Watchguard Firebox X50 (that runs a tunnel with our China operation) over our new Sprint 3 meg connection. Currently, each firewall lives on it's own separate connection.

Potential issues I see involve redirected services, like inbound Terminal Services access, and SMTP. for example, if our router is

175.175.175.1, and the PIX is .2, and the Firebox is .3, will both firewalls try to answer if our internal Exchange server is .4?

Thanks, Brian

Reply to
Brian
Loading thread data ...

Thanks for your post, Volker.

Please note I inherited this network - it was not my design.

Both VPNs use our internal network as the endpoint. Each firewall was chosen as an effort to guarantee stability of the tunnel, as the PIX is connected to another PIX, the Firebox to another Firebox.

I need our internal network to remain the endpoint for both tunnels; servers here are used by both China and Mexico.

Can I have two firewalls be "equals" behind our Internet access router?

Reply to
Brian

Exactly.

Reply to
Brian

In article , Brian wrote: :Can I have two firewalls be "equals" behind our Internet access router?

Only if they are configured for "failover" to each other, or they are configured in such a way that any given transaction is certain to be processed by only one of the two firewalls.

You cannot configure a PIX running 6.x code to selectively proxy-arp (at least not based on level 3 or level 4 information), but you could have an outside router with policy routing that forwarded packets selectively to the PIX's outside interface IP. To ensure that replies went back to the PIX, you would either have an inside router with a suitable policy routing, or else you would configure the PIX to NAT the incoming -source- IP (normally it would de-NAT the incoming -destination- IP); then packets would effectively be tagged as to which of the firewalls they came in on.

Also, on a PIX if you do not static or nat an inside IP, then the PIX will not proxy-arp for the IP. Thus if you

static (inside,outside) 12.13.14.15 192.168.14.15 netmask 255.255.255.255 0 0 static (inside,outside) 12.13.14.21 192.168.14.21 netmask 255.255.255.255 0 0

then the PIX would proxy arp for 12.13.14.15 and 12.13.14.21, but not (for example) for 12.13.14.16. Hence, even though the inside interface might be 12.13.14/24, if you do not static or nat a particular IP, the PIX will not actively listen for it -- so if your netscreen -did- proxy arp for the IP, the netscreen would get the traffic.

Reply to
Walter Roberson

You should consider a zone concept first. Perhaps it's too less information, what you wrote, to help you more concrete.

If you're unfamiliar with zone concepts, just use the classical three zone concept as a starting point.

This means, there is an "outside" zone, an so called DMZ (demiliarized zone) and an "internal" zone. Usually, the internal zone gets no public IP adresses, and access to the DMZ is filtered to what you want to provide.

Between outside and DMZ, and between DMZ and internal there should be firewalls - filtering boxes.

Then you can decide, to what network you want to have your VPN endpoints.

Perhaps it can be a good idea to have one single firewall as the one between internal and DMZ, which acts also as VPN endpoint for both countries, if both should be in the virtual internal zone (which I don't know, because you did not write details ;-)

Yours, VB.

Reply to
Volker Birk

Perhaps this is a good time to review the design ;-)

Hm... there are standards for doing this, so this is not needed usually.

Yes. This is unusual; and with the requirements you sketched, perhaps this is not necessary.

Yours, VB.

Reply to
Volker Birk

A third idea could be to have two (non packet forwarding between hardware interfaces) VPN endpoints with one interface in the internal net and one in the DMZ, respectively, which only are implementing VPN endpoints, no services, nothing else.

Yours, VB.

Reply to
Volker Birk

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.