NETWORK PRESENCE ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT
 


Search
display results
words begin  exact words  any words part 

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [FW1] Opinon Requested - to NAT or not to NAT DMZ Addresses



Frank,

Actually, I thought of that as well ;-)  You can terminate the VPN
tunnels on the firewall's DMZ interface.  It looks a bit cludgy on
paper, but I havn't run into any real issues with doing it that way. 
FW-1 is a truly flexible product, regardless of their sucky (at times)
support.....

Just my .02p

Jason

Frank Darden wrote:
> 
> Yes but I would be careful trying to private-ip the Firewalls external
> interface if you want to be able to use VPNs. I have seen this implemented
> as well, and it will work, just not with VPN's that terminate at the
> firewall (for obvious reasons)
> 
> > Generally you'll have one NIC as your external interface and your DMZ
> hanging off another. Your external int must have one of your
> > public addresses, so how do you assign public addresses from this same
> subnet to a different NIC on your FW?
> 
> This is where you will need to subnet you address space if its possible. If
> thats not possible, purchase more address space. Otherwise youll need to
> NAT.
> 
> -----Original Message-----
> From: Jason Witty [mailto:[email protected]]
> Sent: Monday, November 13, 2000 2:01 PM
> To: Ian Campbell
> Cc: 'Frank Darden'; 'CryptoTech'; Brian Burns;
> [email protected]
> Subject: Re: [FW1] Opinon Requested - to NAT or not to NAT DMZ Addresses
> 
> Ian,
> 
> Actually, you don't have to publically address your outside firewall
> interface at all(provided your firewall is not terminating your Internet
> circuit.)  If your firewall simply talks to a border router (which is
> usually the case), then it's quite easy to set up a privatly IP'd
> transport network between the firewall and the router.  Then you can use
> all of your public space in the DMZ.  I wouldn't recommend that for all
> situations, but it's definitely do-able (I have around 50 firewalls and
> most of them are private externally and internal, with public DMZ
> segments.)
> 
> Just a thought.  Hope it helps!
> 
> Jason
> 
> >
> >    RE: [FW1] Opinon Requested - to NAT or not to NAT DMZ Addresses
> >    Date: Mon, 13 Nov 2000 10:15:12 -0800
> >    From: Ian Campbell <[email protected]>
> >      To: "'Frank Darden'" <[email protected]>, "'CryptoTech'"
> <[email protected]>,
> >         Brian Burns <[email protected]>
> >     CC: [email protected]
> >
> > Just as a logistical issue\question as well:
> >
> > Generally you'll have one NIC as your external interface and your DMZ
> hanging off another. Your external int must have one of your
> > public addresses, so how do you assign public addresses from this same
> subnet to a different NIC on your FW?
> >
> > Ian
> >
> >      -----Original Message-----
> >      From: Frank Darden [mailto:[email protected]]
> >      Sent: Sunday, November 12, 2000 7:54 AM
> >      To: 'CryptoTech'; Brian Burns
> >      Cc: [email protected]
> >      Subject: RE: [FW1] Opinon Requested - to NAT or not to NAT DMZ
> Addresses
> >      Importance: High
> >
> >      Speed, and capability as well. You need to know (or at least have a
> rough idea) how many concurrrent connections
> >      will be going through the firewall. NAT can seriously drain the
> 25,000 default connections because it requires 2x
> >      the connections running through the firewall. This ordinarily does
> not present a problem on smaller sites, however if
> >      you anticipate your site will be hugely popular (dont we all) such as
> a large ecommerce site, you might want to
> >      consider not natting to the DMZ. There are ways to go beyond 25,000
> connections, that are documented at Phoneboy.
> >      But then you start having preformance issues as indicated by
> CryptoTech. I suppose there are some advantages to
> >      natting the DMZ such as flexibility in addressing, and limiting the
> ability for you or others to to shoot yourself in the
> >      foot, and the #1 reason lack of valid address space. Many times the
> situation is one that you have little or no choice to
> >      NAT the DMZ. However if you do have the choice, and practice
> reasonably good management of the firewall and DMZ,
> >      I see no reason to NAT the DMZ. Bear in mind if you do not NAT the
> DMZ your antispoofing rules become more
> >      critical than ever before.
> >
> >
> >      Frank
> >
> >
> >           -----Original Message-----
> >           From: CryptoTech [mailto:[email protected]]
> >           Sent: Saturday, November 11, 2000 9:20 AM
> >           To: Brian Burns
> >           Cc: [email protected]
> >           Subject: Re: [FW1] Opinon Requested - to NAT or not to NAT DMZ
> Addresses
> >
> >           Speed.  Firewall load.  Latency.  NAT modifies every packet
> involved in the rule, and thus add
> >           latency.  If you are running 100mb or higher, you probably don't
> want to use nat
> >
> >           HTH,
> >           CryptoTech
> >
> >           Brian Burns wrote:
> >
> >             I am doing a redesign of our existing network and have been
> asked to use private addressing with
> >             NAT. I am not pro/against it - but I have always used valid
> addresses on my DMZ servers. So... why
> >             would one want to use NAT on your DMZ devices? Comments? Brian
> 
> ============================================================================
> ====
>      To unsubscribe from this mailing list, please see the instructions at
>                http://www.checkpoint.com/services/mailing.html
> ============================================================================
> ====


================================================================================
     To unsubscribe from this mailing list, please see the instructions at
               http://www.checkpoint.com/services/mailing.html
================================================================================



 
----------------------------------

ABOUT SERVICES PRODUCTS TRAINING CONTACT US SEARCH SUPPORT SITE MAP LEGAL
   All contents © 2004 Network Presence, LLC. All rights reserved.