SecureClient Issues

[generalit]

Hi All,

Just a quick overview of network configuration:

Head Office: 192.168.1.0 255.255.255.0
NGX Gateway Internal Address: 192.168.1.245 255.255.255.0

Branch 1: 192.168.2.0 255.255.255.0
Branch 2: 192.168.3.0 255.255.255.0

I have been developing a VPN option for my company using secureclient NG_AI_R56. VPN connections are working fine when users need to connect to Head Office from outside the network.

All secureclient users within the Head Office gateway works fine (meaning when they are on the local subnet 192.168.1.0, connectivity works. It also works when they need to connect to branch 1 and 2 local subnet through the private network).

The only issue i have is when secureclient users in branch 1 and 2 local subnets (192.168.2.0 or 192.168.3.0), are unable to connect to head office through the private network). I receive the following error in the secureclient event log: SPI,encryption fail reason:: secureclient in disconnect mode- no trap for resolving.

To me that tells me, its looking for an encypted tunnel ie when secureclient connects. But in this case, the users are not connected because they are inside the corporate network.

I have confirmed the following test results.

1) NGX gateway is able ping the branch 1 and branch 2 subnets. (So routing is working)
2) Branch 1 secureclient users can ping branch 2 subnet. But is unable to ping head office subnet and then they receive the error listed above.
3) I am unable to ping secureclient users in branch 1 or 2 from headoffice.

I have allowed the follwing rules on the desktop security page (Which i thought would allow for branch office users to connect to head office)

Note: The following groups have been setup that are used on the rule page:
GRP-Internal-Network (This group contains the network address and subnet of Head Office, Branch 1, Branch 2)

Inbound

Source = GRP-Internal-Network / Desktop = ALL users@any / Service = Any / Action = Accept

Outbound

Desktop = All users@any / destination = GRP-Internal-Network / Service = Any / Action = Accept

I have tried everything i know to help resolve this issue (I have only started to learn checkpoint). Their must be a configuration issue on the NGX gateway to allow users to connect to headoffice from the branch offices.

Any help would be great.

Just to confirm, users needing to connect to head office from a remote vpn connection works fine. The only issue is when users plug back onto the corporate network from branch 1 or 2, are unable to connect to head office local subnet.

[chillyjim]

Assuming you are not looking for users in the remote offices to VPN to the local gateway, have them disable securecleint when they are local. What is happening is SC see the computer try to contact something in the encryption domain that isn't a locally attached address so it tries to bring up a tunnel.

I have always found it easer to set SC to manually connect instead of automatically, but that's me.

[generalit]

Hi chillyjim, thanks for your comments.

As you said, im not looking for remote offices to vpn to the local gateway because head office and remote sites are connected via a MPLS private core network.

I really dont want users to have the option to disable the client, as i have not allowed this option in the packaging tool.

Why is head office showing an encryption domain for remote sites that isn't a locally attached address. But when remote sites communicate with other remote sites through the MPLS cloud, the communication works?

All SC are configured to manually connect instaed of automatically.

How do I stop head office from showing remote sites it’s an encrypted domain when its not. Especially when they are connected locally on the MPLS network cloud.

[melipla]

Originally Posted by generalit

But in this case, the users are not connected [with secureclient] because they are inside the corporate network.

And therein lies your problem. I'll kindly refer you to sk23256:

Solution ID: #sk23256

Product: SecureClient
Version: NG
Last Modified: 15-Apr-2005
Symptoms

* Outbound packet dropped with error in SC log: "secureclient in disconnect mode - no trap for resolving"
* Setting "allow_clear_traffic_while_disconnected" to true does not help.
* Setting "send_clear_traffic_between_enc_domains" to true does not help.

Cause
This error can occur in the following scenario:
- There are 2 sites created in SecureClient.
- SecureClient is in Connect Mode, but is disconnected.
- SecureClient has an IP address that is within site A's VPN domain.
- SecureClient is attempting a cleartext (unencrypted) connection to site B's VPN domain (for example, a CPMI connection to site B's SmartCenter Server).
Solution
This type of connection is not supported by design. There are three workarounds:

1. "Connect" with SecureClient to the target site (site B in the above scenario) so the connection is encrypted.

2. Temporarily disable site B (in the SecureClient GUI) in order to make the cleartext connection.

3. Stop SecureClient in order to make the cleartext connection.

Because you don't allow your users to disable SecureClient, then you're forcing your remote office users to use SecureClient even when they're in the office.

The previous SK mentions a workaround which may work for you, I'll refer you to sk25098:

Solution ID: #sk25098

Product: SecureClient
Version: NG, NG AI
Last Modified: 25-Apr-2005
Symptoms

* Outbound packet dropped with error in SecureClient log: "SecureClient in disconnect mode - no trap for resolving"

Solution
Configure VPN-1 SecuRemote and SecureClient to send traffic in the clear to addresses inside the encryption domain while disconnectedEdit the following parameter in the userc.C file on the SecuRemote/SecureClient PC, then stop/start the client:

allow_clear_traffic_while_disconnected (true)

Note: This setting will prevent the encryption domain topology from being loaded by the SR client when it is disconnected. This will allow clear traffic to leave the client PC destined to addresses in the encryption domain.
Applies To:

* Connect Mode
* Userc.C
* allow_clear_traffic_while_disconnected
* AI, FP3

I can imagine that if you're not allowing your users to disable SecureClient then perhaps you don't approve of sending traffic in the clear? If so then "send_clear_traffic_between_enc_domains" may be what you need.

[generalit]

Hi Melipla,

Thanks heaps for the detailed response. I still feel there is a configuration issue somewhere because when my SC users are part of Branch 1 or 2 LAN, they can communicated with each other between branch 1 and 2 through the corporate network.

I only find the issue when SC user’s part of Branch 1 or 2 LAN cannot communicate with Head Office LAN through the corporate network. This is when I find SC thinks it needs to create a secure encrypted VPN connection.

My logic is, if head office, Branch 1 and 2 are all connected in the one domain on the corporate network, and if SC users from branch 1 and 2 can communicate with each other, why does it not work when they need to connect to head office LAN from branch 1 or 2?

[melipla]

Originally Posted by generalit

My logic is, if head office, Branch 1 and 2 are all connected in the one domain on the corporate network, and if SC users from branch 1 and 2 can communicate with each other, why does it not work when they need to connect to head office LAN from branch 1 or 2?

The answer is most likely related to a VPN domain issue. Do you not have Branch 1 or Branch 2 in the remote access encryption domain? That would explain why you can communicate between the two without secureclient blocking the traffic for failure of being encrypted.

[generalit]

Hi melipla,

Thanks for your reply. I thought it might be best if i upload a network diagram of the network, which im trying to describe.

Please see attached. Network.zip

As you can see, Head office, branch 1 and branch 2 are desined to be part of one LAN. Between these sites, their are no VPN configured to allow these connections to occure.

All users on SC have no issue connecting via the WWW cloud to Head office network 192.168.1.0.

The only issue i have is when SC users part of the branch 1 or 2 LAN, cannot connect to head office LAN via the ISP carrier private network.

The strange thing is, users in branch 1 and 2 can communicate with each other when part of the LAN.

To answer your question, does branch 1 and 2 need to be part of the encryption domain? considering traffic between each office does not need to be encrypted as they are part of a LAN done via the ISP carrier private network.

When SC users are part of branch 1 or 2 LAN, and try and communicate with each other, the traffic is passed through in clear, its not encrypted. But when the same SC users try and communicate with the head office LAN via the ISP carrier private network, SC some how see the traffic as encrypted and as a result blocks the connectoin, because the users have not connected on the SC VPN (Considering they dont need to connect the SC VPN as they are part of that corporate LAN done via the ISP carrier)

I hope im making scense here :)

Thanks.

[lowfell]

Hello Generalit.

I seem to be having EXACTLY the same issue. I have now gone away and asked my users to try the editing of the User.c file & see what happens.

However, being totally frank here i put it down to Checkpoint just being crap!

I also have issues with Secureclient and certain makes of endusers routers

I have never had ANY issues using cisco vpn clients!


WHY IS CHECKPOINT SO CRAP AT TIMES?

I know this is no help to you, but I'm just venting my frustration, I bet you know how I feel ?

[generalit]

It sure is frustrating.

Does anyone have any ides on a solution?

[RayPesek]

Can I try to distill this down a bit? I am assuming the SecureClient users do NOT have the VPN fired up for these questions.

1. Can a SecureClient user on the 192.168.1 network work with devices on the .2 and .3 networks OK? (I think the answer is yes)

2. Can a SecureClient user on the .2 network work with devices on the .3 network and vice versa? (I think the answer is yes).

3. Is the problem that SecureClient users on either the .2 or .3 networks cannot work with devices on the .1 network? (I think the answer is yes.)

4. Which networks are in the VPN Domain of the .1 firewall?

5. Is SecureClient configured for Connect mode? (I think the answer is yes.)

6. When you made the manual changes to userc.C, were both SecureClient services on the computer stopped? If not, your changes will get overwritten.

7. Have you changed the property IKE_use_largest_possible_subnets from the default of true to false using GUIdbedit? I'm not sure if this affects remote access but it will affect site-to-site connections, so it is a good idea to make this change anyway. If you make this change, make sure you push the policy and that you have topology updates set to something reasonable, like one hour, not the default of a couple of days. Actually, you should set it to one hour anyway so any changes you make get picked up on the next connection by SecureClient. (Yes, if you add the .2 and .3 networks into the VPN Domain, the SecureClient users will have to connect once just to pick up the change. They can do it from behind the firewall.)

Check Point, for whatever ancient reason, will supernet adjacent networks in a VPN Domain into one big network by default. So if you have the .1, .2 and .3 networks in the VPN Domain, it will send the topology to the other side as a single 192.168.1.0/22 network instead of as separate /24 networks.


I have effectively the same configuration as you and I do not have these issues with SecureClient NGX R60. I did make the same changes in userc.C but all networks behind the firewall are in the VPN Domain in my configuration. If you do not want the remote users to be able to work with the .2 and .3 networks remotely, just put in a desktop security rule to stop it. I have the same "all users@any" rules as you do to permit unimpeded connectivity while on the LAN.

So the good news is it should work fine for you.

For the problem with SecureClient not working behind some home routers, make sure the firmware is up to date. Linksys had problems with old firmware and D-Link never did fix some of their issues. In all cases with us, using SecureClient in Visitor Mode allowed it to work behind even those defective routers. Also make sure you have enabled UDP Encapsulation and IKE over TCP on the gateway object and in the remote access connection profiles.

There is no comparison in capabilities between SecureClient and Cisco. There are a lot more protocols in use with SecureClient for the desktop firewall. SecuRemote is more akin to Cisco.

HTH,

Ray

[generalit]

Hi Ray,

Thanks for your response. Please see below for answers to your questions:

The secureclient users do not initiate a VPN connection while on the .2 or .3 LAN.

1. The answer is YES
2. The answer is YES
3. The answer is YES
4. I’m not certain about this, so maybe you can help me find out the configuration. From what I know the setting is “All IP addresses behind gateway based on Topology information” is selected.
5. The answer is YES
6. and 7. I did not make changes to the user.c file.

Do you think it’s a VPN domain config problem?

[RayPesek]

I always set the VPN Domain topology manually. It's on the firewall object, I think the Topology section, near the bottom of that dialog box.

Create a group and add the three networks into it. If you don't have the network objects created, please do so. Then reset the VPN Domain to the group you created.

Don't forget about the Remote Access topology update time before you connect or do a manual site update and see what happens.

Ray

[generalit]

Hi Ray,

I have made the configuration change and include my local networks to be set as the domain VPN. I will let you know of the results.

Just a question, the section for “Set domain for remote access community” Does this need to be configured? At the moment its set as my remote access community to be set as same as gateway for VPN domain.

[lowfell]

Generalit. Do you have your encryption rule above the rule that allows the traffic between the relevant lans? If so you might want to swap them around?
It's something I've been thinking of trying to see if that makes any difference.

[RayPesek]

NGX is the first version to let you have different VPN domains for site-to-site VPNs and for remote access, should you need to do it. In all previous versions there was no way to separate them. You should be OK with them the same.

Ray

[generalit]

Hi Ray,

It looks like setting the local subnets to be part of the VPN domain WORKS.

I would like to say thanks to all for your help and troubleshooting. Thanks heaps.

PS. Lowfell: My encryption rules have are set below the local outbound traffic.

[RayPesek]

That's great news! Thanks for the feedback,

Ray