Quote:
| 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?
Quote:
| 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).