[FW1] re: work/home laptop, securemote client

[Robert Carr <rcarr6502@FW1-NOSPAMyahoo.com>]

Problem:

Given a SecuRemote userc.C file which defines the
following:

:topology (
: (
:name (ExampleCom.fw1)
:type (gateway)
:ipaddr (169.254.1.1)
:ipmask (255.255.255.255)
)
: (
:name (ExampleCom.fw1)
:type (gateway)
:ipaddr (10.1.0.1)
:ipmask (255.255.255.255)
)
: (
:name (ExampleCom.Net-10-0-0-0)
:type (network)
:ipaddr (10.0.0.0)
:ipmask (255.0.0.0)
)
: (
:name (ExampleCom.Net-192-168-0-0)
:type (network)
:ipaddr (192.168.0.0)
:ipmask (255.255.0.0)
)
)
     ...
:dns_servers (
: (dns1.fw1
:obj (
: (10.1.2.11)
)
:topology (
: (
:ipaddr (10.0.0.0)
:ipmask (255.0.0.0)
)
: (
:ipaddr (192.168.0.0)
:ipmask (255.255.0.0)
)
)
:domain (
: (
:dns_label_count (4)
:domain (.example.com)
)
)
)
)

the decision to build a VPN and encrypt traffic is
(apparently) decided based on IP destination and/or
destination domain.  So if you have SecuRemote
installed on a laptop, plugged into the *CORPORATE
LAN* on the 10.1.1.0 network, SecuRemote will start up
no matter what (especially if you have SDL enabled),
and normal intranet traffic -- destined for other
10.x.x.x or 192.168.x.x nets or internal example.com
hosts -- will unnecessarily be shoved into the VPN,
sent out of the enterprise and back into
ExampleCom.fw1's external interface (169.254.1.1).

Result: unnecessary taxation of local computer and
firewall.

SecuRemote -- which most of us would have enabled as
service which starts automatically -- apparently
doesn't have any way to know that you're not "remote"
and a VPN is unnecessary.  (Checking your local IP
address to see if it falls into any of the nets
defined in your userc.C topology would fix that).

What can be done about it?


Rocky Stefano wrote:
>>
You have a rule that allows a vpn connection to be
intiated from the private network. The vpn network and
encryption domain should only allow connections
from the outside in. That would solve your problem.
<<

True, I have a rule which allows any to initiate VPN
traffic.  That "any" would, by definition, include the
private network presently.

But does modification of that rule really solve the
problem, or just prohibit the completion of the VPN
and break the corporate-residing client, resulting in
support calls from users about how the local network
is down and the internet is broken?


Robert MacDonald wrote:
>>
SecureRemote, when setup properly, will function very
well and never needs to be killed. Is your encryption
domain setup correctly? This should encompass the
networks inside of your private network. This way,
when SecureRemote detects that you have local
connectivity, it will just ignore all requests and
allow traffic to pass as local traffic.
<<

I believe I have the encryption domain set up
properly, and the topology() statements above, in each
user's userc.C define only the internal networks.

My Logview would dispute that SecuRemote can detect
that you're in the same network as the "encryption
domain."  I see VPN connections from
internally-residing SecuRemote machines all the time. 
Only manually killing SecuRemote will stop this and
allow the machine to function sans VPN on the local
LAN.

Robert MacDonald continued:
>>
When SecureRemote detects traffic bound for your
encryption domain and it does not have a local
connection, SR will spring to life.
<<

I have SecuRemote starting as a service, under WinNT
and SDL is enabled so that users can go home, boot up,
and "log into the domain" as though at work.

It appears to me that SecuRemote doesn't know or care
whether you're local to the encryption domain or not.

Robert MacDonald continued:
>>
A problem that occur often is, the system in question
has an IP address in the encryption domain while
remote. If this happens then SR will think it's still
local.
<<

I have just the opposite problem.  SecuRemote is
installed on a laptop that often is remote (static IP,
residing on a home DSL net for instance).  But when
the laptop is brought in house, DHCP configured, given
an IP on the corporate LAN -- which is also in the
encryption domain -- SecuRemote still creates a VPN
because the destination of the user's traffic is in
the encryption domain.

Robert MacDonald continued:
>>
Do you have different setups for these users at home
vs work or are these machines equipped with a docking
station at work and a PCMCIA at home?
<<

Built-in ethernet card -- plug in local LAN or plug in
DSL/Internet.  Users are manually reconfiguring
Network settings when home for a public, static IP. 
Manually reconfiguring for an RFC 1918 private, DHCP
address when at work.


Matt Bruce confirmed he has the same problem:
>>
As you mention, I just Kill my client whenever I'm in
the office.
<<


Gijs Wuyts wrote:
>>
How about Nt's Boot profiles ?
<<

I am not a Windows person per se; I'm not familiar
with NT boot profiles nor do I know if they would
solve this or the problem of corporate users going
home to a static IP environment or coming to work in a
DHCP environment and needing to seemlessly switch
between the two.

I'm hoping someone who is more familiar with NT boot
profiles could verify that.


Michael Haller wrote:
>>
Can you use NT startup profiles for this?
You could create a remote and office profile.
You users will still need to choose the correct
profile at system startup but it shouldn't be
too hard.
<<

The startup profile would address the DHCP/static IP
problem.  Can you suggest a resource to find out more
about this?  Microsoft's site is not especially
helpful despite the pages of irrelevant search results
it returns.


Thanks for all your help and suggestions with this.

__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/


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