SecureClient connection dropping

[thefunkygibbon]

Hi,

having a problem with my users secure client access. they seem to be dropping and needing to reauthenticate every so often, seemingly random. the logs show the following

message: remote access client IP address and port were changed
old IP: 82.x.x.1
old port: 17904
new IP: 82.x.x.1 (same as above)
new port: 18106



any ideas?

new install of r60 on vrrp nokias (2 of) and a splat management.

[alienbaby]

Sounds like the user is behind a NATing device (Linksys,Netgear,etc.) and it's State table is timing out; probably an idle connection. When the UDP encapsulated VPN traffic resumes from the user's computer, the NATing device chooses a different NAT'd source port for the connection.

On R55 , you can enable keep-alives under Policy Menu / Global Properties / Remote Access / Enable Back Connections.

This assumes that the device is functioning properly. If it's being power cycled, or if it's state table is being overrun by a worm inside that home network, then you have other problems.

[thefunkygibbon]

apparently this is happening for all users. I agree it looks like some kind of NAT'ing issue from thier end, but i dont belive everyone has same routers/modems/firewalls or even a worm.

i have already enabled keep alive for back connections on the fw and is set to the default 20 secs, i'll try something a little more frequent.

[giduser]

I am having an identical problem. I have several sites that are dropping several times a day. Some are behind a D-link 604 router and others a Sonic Wall Firewall. I have already enabled keep alive for back connections on the fw and is set to the default 20 secs, same results. I have re-loaded clients and used CP Clean. Improved drops but still happening several times a day. I received a new version fof client from Checkpoint, no good. Would love to know if you had any success. Thanks.

[melipla]

Have you seen this SR?

SmartView Tracker displaying Nokia Gateway error: "Remote access client IP address and port were changed"
Print this Solution
Email this Solution
New Search / Advanced
Next Solution
Solution ID: #sk26410

Product: SecureClient, VPN-1 Pro (VPN-1/FW-1)
Version: NG, NGX, NG AI
Last Modified: 24-Apr-2006
Symptoms

* SmartView Tracker displaying Nokia Gateway error: "Remote access client IP address and port were changed"

Cause
The objects_5_0.C property value om_enable_with_multiple_IF is set to true. This attribute is used for Office Mode, when the Security Gateway has multiple external interfaces. This feature is not supported on the Nokia platform.
Solution
To resolve this issue, clear the box SmartDashboard > FireWall-1 Gateway Object > Remote Access > Office Mode > "Support Connectivity Enhancement for Gateways with Multiple Interfaces", for Office Mode.

This issue occurs only on Nokia.

NGX and NG with AI R54/R55
This option is set to true by default on VPN-1/FireWall-1 NG with Application Intelligence R55. Clear the box SmartDashboard > FireWall-1 Gateway Object > Remote Access > Office Mode > "Support Connectivity Enhancement for Gateways with Multiple Interfaces", and modify the $FWDIR\conf\objects_5_0.C property om_enable_with_multiple_IF to false per the "NG FP3" steps below.

NG FP3
Modify the objects_5_0.C property om_enable_with_multiple_IF, and set it to false.

On the SmartCenter Serve:

1. Close all SmartConsole connections (SmartUpdate, SmartDashboard, etc.).

2. Use GUIdbedit to modify the property Table > Network Objects > Network Objects > Gateway_Object > om_enable_with_multiple_IF , by setting it to false.

3. Update network_objects firewall_module. The system displays the message, "firewall_module updated successfully."

4. Type quit to exit GUIdbedit.

5. Log in to SmartDashboard.

6. Install the Security Policy.

[giduser]

I am currently running two servers on Secure Platform, no Nokia box involved.

[melipla]

That SR was mainly for thefunkygibbon.

One question, do you have users that don't get reprompted? Can you identify which interface they're authenticating to? (If you turn off IP resolution in the tracker, it should give you the interface IP)

I'm seeing a similar problem with users being reprompted to authenticate to a firewall they're already authenticated to. I've noticed that users were authenticating to any interface on the FW & those that authenticated to the "internal" interfaces appeared to have the reprompting problem more frequently. Forcing secure client to only authenticate to the external IP of the firewall has greatly reduced the number of repromptings but hasn't eliminated the problem.

[giduser]

All users experiencing drops will be prompted to log in to the firewall again. This happens randomlyseveral times a day. I do have some users experiencing problems locking up in Outlook that don't get prompted.

I turned off IP resolution and it seems that all login attempts are to the same external interface. In this case the firewalls are on a service network and all VPN requests are routed to this external firewall interface.

How can I verify secure client is being forced to authenticate to the external IP?

[melipla]

Originally Posted by giduser

All users experiencing drops will be prompted to log in to the firewall again. This happens randomlyseveral times a day.

Sounds similar to my problem. Is your remote access gateway running secure platform and R60 HFA 3? Is your remote access gateway a cluster object? Do you have more then one gateway in the Remote Access community?

Originally Posted by giduser

I turned off IP resolution and it seems that all login attempts are to the same external interface. In this case the firewalls are on a service network and all VPN requests are routed to this external firewall interface.

How can I verify secure client is being forced to authenticate to the external IP?

You would see it in the log file if they were authenticating to other IPs. For me, when secure client is connecting initially, I see RDP packets from the IP address of the secure client machine to the IP of each interface on the remote access gateway. It appears to be a probe for the fastest interface. Since all interfaces are routable via the internet, some of the clients were authenticating to the IP address of my "internal" interface of the gateway. By blocking the RDP packts to the IP(s) of the internal interfaces on the edge router, then that forced secure client to use the external IP of the gateway. It didn't solve the problem, but reduced the number of people who complained about the problem.

I've sent a lot of debugs to checkpoint and they seem to think that Secure Client is timing out it's connection & that the reprompt is somehow valid. Here's a list of what checkpoint has had me do in order to try to resolve this problem:

use secure client version R60 (HFA01)
disable MEP (gateway object properties -> remote access -> office mode -> multiple interfaces checkbox)
disable toplogy updates (policy -> global properties -> remote access -> update topology)
authentication timeout -> use default (policy -> global properties -> remote access)
enable back connections -> every 20 seconds (policy -> global properties -> remote access)
create a new user (post NGX upgrade) and see if that user experiences the same problems as the pre-NGX users

I've done fw monitors on my remote access gateway in order to catch a reauth. I've done srfw monitor's on secure client machines in order to capture a reauth. No one seems to know why secure client is prompting to reauthenticate. You can enable the logging on the secure client machine via the command line with a "sc log on" or a "sc debug on" from the c:\program files\checkpoint\secure client\bin\ directory. This will create seemingly very detailed logs in the secure client directory. You can verify which interface secure client is connecting to from these logs as well (the ips are all in hex).

[Friedrich]

Hi,

Just have a simular problem.
On the FW I see the error:

MAC: xx-xx-xx-xx-xx-xx; OM: -requested address is assigned to another client; om_method: IP pools

A lot of users have the same mac address. I think that a random mac address is choosen at installation time for the virtual adapter (we're using office mode). But because we're using RIS, all virtual adapters for a particular image have the same mac address. This can explain why this is hapening.

Maybe this is also the case for your problem.

Is there a method for recreating the virtual mac address?

[iea38]

Did anybody find a solution for this problem ? We do have the same issue
between secureclient r60 hfa02 and NGX R62, if we downgrade to
r56 hfa03 then the issue goes away. Secureclient r60 hfa02 supplement 1 times out every few minutes making it unusable. Upgrading to supplement 2
is better, session lasts between 1 and 2 hours before reauthentication.

[lodown]

I had this issue with a particular build of R60 Secure Client. It seemed to happen more often with wireless/wifi. We upgraded to the latest build and that fixed the issue(downgrading will also solve the problem).

SecuRemote on 3G Internet Connection

lodown

[melipla]

Originally Posted by iea38

Did anybody find a solution for this problem ?

Are you using a clustered gateway? Have you ever tweaked the timings in Global Properties?

[iea38]

Yes, it is a clustered gateway (clusterxl, one of the gateway in standby mode,
running R62). The TCP start/session/end timeout are 25/7260/80. UDP/ICMP/other timeouts are 80/30/60.

I also had another module that was not clustered - I removed it, and it did
get better (so we suspected MEP), but now it is prompting every 30 mins
to reauthenticate.

[melipla]

I've experienced a similar problem with an NGX clustered environment, only it wasn't as timely as yours. My problem ended up being the fact that SecureClient was attempting to re-establish its connection with the gateway via an internal interface instead of the external interface it used initially.

The fix was to use guidbedit and search for this property:

apply_resolving_mechanism_to_SR

For cluster objects its set to False by default, you'll want to set it to true and repush the policy to the gw [and update site?]. Check out SK32229 which talks about the resolving mechanism and SK22020 which talks about SecureClient's resolve_multiple_interfaces property.

[iea38]

My apply_resolving_mechanism_to_sr is set correctly to true, and
link selection is set to use the main address.

I suspect clusterxl sync issue. If I "cpstop;cpstart" the cluster module
that is in passive mode, then the issue goes away for a while.

[melipla]

Originally Posted by iea38

I suspect clusterxl sync issue. If I "cpstop;cpstart" the cluster module that is in passive mode, then the issue goes away for a while.

That sounds odd, as shutting down your standby cluster member should not affect whether or not your remote access users are prompted unless there are serious issues with cluster configuration. Is your HA cluster stable?

Have you identified which gateway is causing the prompts (I'm assuming you have more than one gateway in your RA community)?

[iea38]

I started seeing reauthorization prompts not only for secureclient R60 hfa02 build 52, but also for secureclient R56 hfa03 build 619 clients as well.
R62 clusterxl was stable for other connections.

In view that there were reports that my setup should be working, I upgraded
to R65 hfa02. So far, so good. All frequent reauthorizations are gone -
the software is working as it should.

[melipla]

Originally Posted by iea38

In view that there were reports that my setup should be working, I upgraded
to R65 hfa02. So far, so good. All frequent reauthorizations are gone -
the software is working as it should.

For clarification, you're referring to the gateway which you upgraded to R65 HFA 02?