Not specifically with a PIX, but I have had occasion to have
lines/addresses from multiple ISPs mapping to the same host. The
only firewall issue was to ensure that return packets get NATted
according to the particular rule/conduit used to set up the inbound
connection -- and I think a NAT implementation that doesn't work that
way may break on other scenarios as well.
Where the networking gets tricky is that the routing of outbound
packets -- selection of a route/gateway back to the Internet -- is
going to be based on the remote client's IP address, NOT on which IP
range it addresses the server by. So you may routinely see sessions
where the inbound packets arrive from ISP A, because they administer
the address space containing the server address chosen by the client,
but return packets are sent via ISP B, because that's how your
routing is set up.
The thing is, all the client and server care about are the endpoint
addresses. The only time anyone would know that this is going on,
besides you, is if they could get a traceroute from each end and
compare the two.
As far as multiple interfaces: What I've done is allocate the
inboard interface addresses of my gateway routers, and the untrusted
interface of the firewall, from the IP range offered by ISP A, and
told router B that the firewall was the next gateway to the range
offered by ISP B. Then the whole subnet can be on a small hub or
switch, and only one firewall port is needed. Hmmm.... Maybe the
PIX can't have conduits mapped to subnets other than the one the
interface is directly connected to?
David Gillett
On 4 Jun 2001, at 16:17, Harry Whitehouse wrote:
> Shawn
>
> This looks very interesting! Thanks for sharing!
>
> >>Bear in mind I haven't done it myself.
> >>However, I do successfully use different public IP's (from different
> >>interfaces) homed to the same internal host in my network on my production
> >>PIX.
>
> I don't quite understand the above. It sounds like you *are* doing exactly
> what I need to do if you have two public IP's targeting the same internal
> hosts-- but you do it on a production basis rather than just in a
> transitional mode. I must be missing something!
>
> BTW, we also are tempted to continue using our "old" ISP in conjunction with
> the "new" one to provide some access redundancy. We have had occasions
> where our old ISP has had outages and certain areas of the country haven't
> been able to access us for hours or sometimes most of a day. But I gather
> that doing this requires that we obtain a special range of "universally
> recognized" IP addresses and then have each ISP map these IP address to our
> URL names.
>
> If you don't mind me asking, how are you using the two ISP's to your
> benefit?
>
> Finally, if I use the DMZ interface card on my PIX (currently unused), can I
> plug that into a network cable that has both ISP's "resident on that line?
> IOW, we have two distinct T1's/routers from the respective ISP's. Both
> routers then plug into our main network cabling infrastructure. So will it
> work if I plug in one of these network cables into the OUTSIDE PIX card and
> another into the DMZ card, and configure as you have suggested?
>
> TIA
>
> Harry
>
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Shawn Savadkohi
> Sent: Monday, June 04, 2001 3:45 PM
> To: 'Harry Whitehouse'; Firewall_List
> Subject: RE: Configuring a PIX 520 to handle Multiple ISP's
>
>
> Given that you have a 3rd interface in your PIX that isn't being used, you
> should be able to do it - presuming that traffic from your new ISP comes in
> a separate interface (or router). Bear in mind I haven't done it myself.
> However, I do successfully use different public IP's (from different
> interfaces) homed to the same internal host in my network on my production
> PIX.
>
> Here's a suggestion config that comes to mind (using DMZ1 as interface
> name):
>
> -------------------------------
> nameif ethernet0 outside security100
> nameif ethernet1 outside security0
> nameif ethernet2 dmz1 security50
>
> ip address outside 38.168.115.180 255.255.255.0
> ip address inside 192.168.x.x 255.255.255.0
> ip address dmz1 64.107.193.x 255.255.255.0
>
> global (outside) 1 38.168.115.160-38.168.115.179
> nat (inside) 1 192.168.x.x 255.255.255.0
>
> static (inside,outside) 38.168.115.174 192.168.0.174 netmask 255.255.255.255
> 0 0
> static (inside,dmz1) 64.107.193.y 192.168.0.174 netmask 255.255.255.255 0 0
> access-list acl_outside permit tcp any 38.168.115.174 eq www
> access-list acl_dmz1 permit tcp any 64.107.193.y eq www
> access-group acl_outside in interface outside
> access-group acl_dmz1 in interface dmz1
>
> route outside 0.0.0.0 0.0.0.0 38.168.114.1 1
> route dmz1 0.0.0.0 0.0.0.0 64.107.193.z 1
> --------------------------------
>
> I refer access lists rather than conduits (they're becoming obsolete...
> notice the thread going around about converting conduits to access lists?).
> There's no GLOBAL statement for the DMZ1 interface, so internal hosts won't
> NAT out that interface.
>
> Regards,
>
> Shawn
>
>
> > -----Original Message-----
> > From: Harry Whitehouse [mailto:[EMAIL PROTECTED]]
> > Sent: Monday, June 04, 2001 2:57 PM
> > To: Firewall_List
> > Subject: Configuring a PIX 520 to handle Multiple ISP's
> >
> >
> > Hi All!
> >
> > We are making a transition between one ISP and another. We
> > have routers for
> > both ISP's now operational on our general network ("outside" the PIX
> > firewall).
> >
> > Is it possible to configure the PIX to handle both ISP's during the
> > transition period at the DNS servers? It is a very simple
> > configuration --
> > here are the lines which have the old ISP addresses:
> >
> > 1. ip address outside 38.168.115.180 255.255.255.0
> >
> > 2. global (outside) 1 38.168.115.160-38.168.115.179
> >
> > 3. static (inside,outside) 38.168.115.174 20.0.0.174 netmask
> > 255.255.255.255
> > 0 0
> >
> > 4. conduit permit tcp host 38.168.115.174 eq www any
> >
> > 5. route outside 0.0.0.0 0.0.0.0 38.168.114.1 1
> >
> >
> > I *do* have three network cards in the PIX -- I'm currently
> > only using two.
> >
> > I would *think* that I could add replicate configuration
> > lines for 3 and 4.
> > IOW, couldn't I add
> >
> > static (inside,outside) 65.107.103.174 20.0.0.174 netmask
> > 255.255.255.255 0 0
> > conduit permit tcp host 65.107.103.174 eq www any
> >
> > and have these coexist with the 38.168.115.174 statements?
> >
> > I'm more concerned with items 1, 2 an 5. But perhaps I can
> > leave them as is
> > until the conversion is completed. For transaction
> > originated from *within*
> > our internal network, I'm happy to use the old ISP until the
> > DNS conversion
> > is complete. What I want to make sure is that folks from the
> > outside can
> > access my internal servers even though some would be routed
> > to the "old" ISP
> > address and others to the "new" ISP address while the new DNS
> > information
> > propagated throughout the www.
> >
> > Can anyone give me some insight on this?
> >
> > TIA
> >
> > Harry
> >
> > -
> > [To unsubscribe, send mail to [EMAIL PROTECTED] with
> > "unsubscribe firewalls" in the body of the message.]
> >
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
> -
> [To unsubscribe, send mail to [EMAIL PROTECTED] with
> "unsubscribe firewalls" in the body of the message.]
>
-
[To unsubscribe, send mail to [EMAIL PROTECTED] with
"unsubscribe firewalls" in the body of the message.]
