SecuRemote on 3G Internet Connection

[TonyR]

Firstly, apologies for the length of this post.

The directors at my office use a Vodafone 3G connection for VPN access whilst out of the office.

They're experiencing a problem whilst travelling on trains - this being that as the 3G connection moves from cell to cell, the client IP address changes. Each time this happens, SecuRemote requests the users password again. Now, I realise this is probably by design, as of course if the client IP changes, then the firewall / SecuRemote must assume a new connection has been made.

My question is; does anybody know a way around this? I thought about using a certificate without a password, but I feel that is perhaps too insecure. I really would like to retain the user / password challenge.

Also, would SecureClient be any better? We don't have any SecureClient licences (and not in a position to purchase any!) but I understand that SecureClient can be used for free, but without desktop policies.

I cannot see this making any difference though, as each time the IP address changes, a new connection is initiated, so I would surely expect the firewall to request authentication.

I am desperate here, as I am under considerable pressure to get this resolved.

Finally the all important versions:
Check Point VPN-1(TM) & FireWall-1(R) NGX (R62) - Build 120
SecuRemote NGX R60 (build 191)

Thanks for reading.
Tony.

[mcnallym]

SecureClient without any SecureClient Licenses is SecuRemote.

I believe that SecureClient with licensing may solve this as would allow you to use office mode. I believe that this would solve as uses a Virtual Network Adaptor to communicate with the Gateway and this has a Virtual Mac that would not change.

However you would need to have SecureClient licenses for this to work.

If you speak with your check point reseller then can probably arrange an eval license for you to try this out.

I don't believe that you will resolve this with Secure Remote.

Alternatively depending upon what you are using this for then may want to look at a Connectra to provide the access as is https rather then IPSEC so should work better for you if roaming around.

[Thorpuse]

The auth challenge will come every time the IP address changes. You can't (and wouldn't want to!) stop this. What you could do is some form of cached authentication, but this also is bad because of the security risk this causes. SecureClient and OM won't help, as the OM negotiation will happen again every time it sees a new IP.

[melipla]

Originally Posted by Thorpuse

The auth challenge will come every time the IP address changes. You can't (and wouldn't want to!) stop this.

Why wouldn't you want to stop this? You've authenticated yourself to the gateway, its not like someone can mitm attack the connection just because the IP has changed. If that were possible then it'd be just as easy [or easier] to mitm attack a connection that uses a static IP. We know the gateway can handle remote vpn peers with dynamic IPs--part of the attraction for Edge devices is that very reason. I don't see why you'd want to stop an authenticated SecureClient device merely because its IP is dynamic.

Having said that, AFAIK the use of certificates would be your only way around this problem.

[lammbo]

Under the Site properties in SecureClient there is a reuse credentials for multiple gateways (I know, not exactly 100% for this scenario). I want to say that this option takes care of the continual prompting if you're using OM. (Note that I am in Traditional mode, so this MAY behave differently if you are running Simplified)

If memory serves me, I think that a few years ago, a director at our UK office complained of the same issue while on trains and this fixed it. I may be confusing different cases though, so try for yourself.

As far as security issues go, since you still have to enter credentials on the initial connection, I have no hangups with re-using the credentials, as some of us do. If you have a security officer at your company, you should probably check in about this before deploying globally.

[lodown]

I ran in to a similar issue with an early build of Secure Client R60 on wireless as well as with my Verizon card. In many cases it was not the IP that changed, but some other property in the TCP/IP configuration. Ultimately a newer build resolved the issue. I wonder if this happens with other versions of Secure Remote, or if it's this particular build. You may want to try and upgrade a single user to a newer version and see if it resolves the issue

lodown