[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [FW1] Passing IPSec traffic
I wonder why one would use another box in tendem rather than just use
the FW-1's IPsec VPN feature.
Y. John Jiang, Internet Engineer, Internet Security, Cable and Wireless
703-715-7480, 2100 Reston Parkway, Reston, VA 20191
On Thu, 18 Feb 1999 bbbrandt@mmm.com wrote:
>
> With IPSec there are 2 sides to NAT.
>
> At the Server side (ie the corporate network), any IPSec gateway product you
> install will do NAT (see rfc2401). This works just fine because on the internal
> interface nothing is encrypted anymore, ie. the traffic has come out of the tunnel.
>
> On the client end is where NAT gets interesting. Lots of cable modem providers,
> ISDN routers,
> other corporate networks do NAT because they don't, or can't, burn public address
> space. We have found
> that you can make NAT work, is 1) you turn off AH (the authentication header which
> is a digital
> signature which includes the IP source address as part of the hash), and 2) as long
> as the NAT device on
> the client end is 1-1 static, or can adequately maintain \an unambigous mapping
> between the nonrouteable
> address and the public address things can be made to work in many cases, but of
> course with NAT, every
> case is custom so your mileage will vary. The good part is that you can turn off
> AH, and just run ESP,
> which does the encryption of the payload, but also has a digital signature (it just
> does not include the
> IP source as part of the hash).
>
> Bob Brandt, 3M
>
> Bixler, Dave wrote:
>
> > We have been evaluating IPSec-based VPN servers as well, and found one
> > interesting thing about the IPSec protocol. According to the vendors I have
> > spoken to, IPSec will not support Network Address Translation ("Address
> > Hiding") in its present form. The vendor we are working with is working on
> > a client-based workaround, but you may want to check with the vendor you are
> > evaluating regarding NAT and their product.
> >
> > Hope it helps,
> >
> > Dave
> >
> > Dave Bixler
> > Senior Enterprise Network Specialist
> > ENTEX Information Services
> > IT / Core Technology Services
> > mailto:dave.bixler@entex.com
> > TMCTL
> >
> > -----Original Message-----
> > From: Tariq Rahman [mailto:trahman@butlerintl.com]
> > Sent: Wednesday, February 17, 1999 5:39 PM
> > To: fw-1-mailinglist@lists.us.checkpoint.com
> > Subject: [FW1] Passing IPSec traffic
> >
> > Hello all,
> >
> > I'm running FW-1 3.0b v3072 on NT 4.0 SP3. We're using Address Hiding to
> > protect our internal network. I'm currently evaluating IPSec VPN hardware
> > for
> > my company and came across something interesting.
> >
> > One of the vendors I'm evaluating has a VPN demo on their site. They allow
> > you
> > to download their VPN client, install it and then tunnel into their network
> > to
> > a web server w/ a private address.
> >
> > I installed their client on my machine and tried to tunnel back to their
> > office, but the FW, which is configured to pass all traffic from my machine,
> > passed the VPN traffic through w/o hiding my IP address.
> >
> > The log entry showed the protocol type, not as TCP or UDP, but as 51, which,
> > I
> > think, is the protocol type for IPSec packets.
> >
> > My question then is, how do I set up the FW to recognize these packets so I
> > can
> > apply accept / drop rules against them?
> >
> > Thanks,
> >
> > Tariq Rahman
> > Butler International, Inc.
> >
> > ============================================================================
> > ====
> > 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
> > ================================================================================
>
>
>
>
>
> ================================================================================
> 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
================================================================================