RE: [FW1] Home/Office NAT range conflicts

[Dan Hitchcock <danh@FW1-NOSPAMxylo.com>]

But wait...

Although what I posted below alleviates the overlapping home network issue,
Jeff Jarmoc's issue is valid: if your SR client has an address that it
believes to be inside the encryption domain, it will never try to encrypt
the traffic.  So, although you won't need to ensure that the remote networks
are unique from each other, you will need to ensure that none of the home
networks overlap your internal networks.

BTW, the information for IP Pool NAT is actually included with the 4.1 OEM
docs (Checkpoint Virutal Private Networks - VPN.pdf pp.247-250).  You must
also make sure to ARP the addresses of the IP Pool to your internal firewall
interface (published arp on *nix, local.arp on NT)

HTSH (Hope That Still Helps :)

Dan Hitchcock
Network Engineerdanh@xylo.com
Xylo, Inc.
The work/life solution for corporate thought leaders


-----Original Message-----
From: Jeff Newton [mailto:Jeff_Newton@pmc-sierra.com]
Sent: Tuesday, January 09, 2001 3:36 PM
To: danh@xylo.com
Subject: RE: [FW1] Home/Office NAT range conflicts



Thanks Dan.  I think I'm going to go this route.  Do you know of any
docs on how to set this up.

Cheers,

>Perhaps this was already posted, but the solution is to run IP Pool 
NAT (new
>to FW1 4.1).  This allows you to accomplish exactly what Jeff 
suggests
>below: translate the SR client's source address to an internal 
address that
>you define (i.e. you define the address range for the pool, and the 
SR
>client's traffic appears on the internal network with an address 
picked out
>of that pool).  This alleviates the possible problems posed by 
overlapping
>home networks.
>
>HTH
>
>Dan Hitchcock
>Network Engineer
>>danh@xylo.com
>Xylo, Inc.
>The work/life solution for corporate thought leaders
>
>
>-----Original Message-----
>From: Jarmoc, Jeff [mailto:Jeff.Jarmoc@Grubb-Ellis.com]
>Sent: Tuesday, January 09, 2001 2:04 PM
>To: 'Jeff Newton'; fw-1-mailinglist@lists.us.checkpoint.com
>Subject: RE: [FW1] Home/Office NAT range conflicts
>
>
>
>Boy, that is a potential problem.. and I hadn't thought about it 
before now.
>NAT probably won't work, because SecureRemote would have to decide 
whether
>or not to tunnel prior to the NAT taking place.  You could just have 
a
>blanket policy that home networks must be 10.x.x.x and keep your 
internal
>networks 192.168, or vice versa.   I'm interested to see if anyone 
else has
>a better technical solution though.
>
>-----Original Message-----
>From: Jeff Newton [mailto:Jeff_Newton@pmc-sierra.com]
>Sent: Tuesday, January 09, 2001 3:51 PM
>To: fw-1-mailinglist@lists.us.checkpoint.com
>Subject: [FW1] Home/Office NAT range conflicts
>
>
>
>
>I have users with private NAT ranges in their home networks accessing
>the office via SecuRemote.  I see a potential problem of ip address
>conflicts with the private ranges used in the office.
>
>Any suggestions for how to deal with this?  I shudder at the idea of
>having to manage/allocate ranges for use in employee's home networks.
>
>Perhaps there is a way to NAT them on the way in?
>
>Cheers,
>
>----
>Jeff Newton
>
>
>
>
>=====================================================================
=======
>====
>     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
>=====================================================================
=======
>====

----
Jeff Newton
Security Analyst
PMC-Sierra Inc.


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