SecureClient blocking access to private networks

[fuzza]

Hi everyone,

We use SecureClient for accessing one of our clients (we are a consultancy) but we have problems in accessing other sites while it is installed on our systems. It seems to block traffic to other private networks, in particular to 10.x.x.x ranges (our internal LAN is on 192.168.73.x).

To test this, I have set up a small stand-alone network, consisting of two PCs on separate 10.x.x.x subnet ranges, connected by crossover cables to different ports of a router (refer to attached diagram). The router is set up to route in between the two networks directly (no NAT is involved). Both networks are /24 subnet ranges, and both PCs have the router (with its respective IP) as their gateway IP address.

Both PCs have SecureClient installed, with the profiles supplied by the relevant client, but the service is stopped (hence no icon appears in the taskbar). All machines can ping each other, and traceroutes show that traffic is (eg.) going from PC 1, via the router as hop 1, to PC 2 as hop 2 (and vice versa).

If the Checkpoint service is then started on PC 1 (without even connecting to any site), the network breaks down. Both machines can still access the router (being on the same respective subnet), but any attempt to access PC 2 from PC 1 fails (no traffic leaves the machine at all). Attempting to traceroute to PC 1 from PC 2 shows that it can reach the router, but cannot receive any reply from PC 1.

In viewing the built-in Checkpoint log on the machine with the running service, outbound packets give the following error:
ICMP:3, ICMP Type:8, ICMP Code:0, spi:, encryption fail reason::secure client in disconnect mode – no trap for resolving

Inbound packets show this:
ICMP:3, ICMP Type:8, ICMP Code:0, scheme::NA, srckeyid: , dstkeyid: , methods::, peer gateway:0, encryption failure::Received a cleartext packet within an encrypted connection, partner:4, community:4

We obviously do not have control over the server end of the Checkpoint service, but we could probably have something changed at a management level, if we knew exactly what needed doing. So... how would you fix this? What setting would you change?

Thanks,
Andrew

[Bob_Zimmerman]

Those errors make it sound like PC2 is in SecureClient's encryption domain. Check with whoever administers the firewall and ask what network ranges are in the Remote Access encryption domain. My bet is that either 10.0.0.0/8 or 10.1.0.0/16 are going to be in there.

If I'm right, then SecureClient is functioning as designed. It cannot possibly know that you have multiple physical 10/8 networks (one on the other side of the VPN and one locally), so it assumes that any traffic to the networks in the encryption domain should be encrypted and sent to the firewall.

There may be a way around this, but if there is, I don't know it.

[RayPesek]

As a consultant, you might want to change your strategy because this is a common problem.

Consider installing Microsoft's free Virtual PC product and creating different virtual machines for each client. That way you can keep all of their files separate from those of other clients and you can have different versions of software installed in each VM. It also eliminates the issue you're having now.

Ray

[fuzza]

Thanks Bob and Ray,

I don't think separating out in a virtual machine is practical, as half of our staff are accountants and it would be too hard for them to get the hang of :(

Re the IP ranges in the encryption domain, that sounds likely - and at least two of the machines we connect to for this client are on 10.0.x.0/24 ranges so they probably are using 10/8.

But why does it insist on intercepting the traffic even when it's not connected to the site? If it is connected I understand that of course, but can it be turned off if disconnected? (Obviously it is there for things like auto-connection of the link, but we do not use that at present, and would not want to.)

BTW in case anyone's wondering, our previous solution to this was to stop the Checkpoint service on the client PC, but that was producing an even more annoying problem, documented in this newsgroup thread.)

Thanks
Andrew

[Bob_Zimmerman]

Well ... you could detach SecureClient from that NIC. That *might* do what you're wanting and it would be a bit less nasty than stopping the service as a whole.

You may also be able to just right-click on the SecureClient icon and pick "Stop VPN-1 SecureClient".

I get the feeling that there's another way around this, though. If you (or the admin of the site you are connecting to) have support with Check Point, I would check with them to see what they think. Even if you don't have support, you should be able to discuss it with your local sales guy.

[mcnallym]

It sounds like as Bob says that the range is part of the encryption domain and so won't send apart from the VPN Tunnel. I am presuming here that all of your clients are using Check Point gateways as you are using SecureClient. Do you just connect to one machine at each location or a number.

The reason I ask is that it sound like rather then using a Client to Site with SecureClient you could build a Site-to-Site VPN with NAT taking place to NAT your machine as it leaves and NAT at the customers end to ensure that there is no overlap with other people.

This also takes the config from the PC's and any issue with connectivity to the Firewalls where you will have the firewall admins with more technical skills, then the end users and makes it much more simple for the end users.

[fuzza]

Thanks Bob and mcnallym,

We're already using "unbind the SecureClient from the NIC" as one of the workarounds for the other problem mentioned, but it's a lot more work than I would like as a permanent solution (accountants, don't forget). And for some reason the version of SecureClient we've been given by the client doesn't allow you to Stop the program via the taskbar icon (the option isn't there). We have to stop it through the Services window.

Re the site layout, we only use Checkpoint for this one client, but they have 4-5 different sites on their WAN which we access (they are an international mining company). All of our other clients are through other means - Cisco VPN, PPTP (preferred), direct telnet/SSH, even kermit for a few. Of course this means interoperating with a lot of different IP ranges, so excluding them all from the encryption domain would be an arms race; I'd rather not have it block anything when it's not in use.

I'm endeavouring to follow it up with the client, though they haven't yet replied to my emails - no idea if they have a support contract with Checkpoint or not. I also applied for an account with the Checkpoint site forums, but haven't received approval yet...

Thanks,
Andrew

[Bob_Zimmerman]

I have been told that stopping Check Point services through the 'Services' manager is an extremely bad idea. That it doesn't stop them cleanly. They include little scripts to cleanly stop their software. I don't know what the script for SecuRemote is, but there probably is one.

So you need to use a package that your client gave you rather than the standard installer? You might want to see if you can use a "normal" version that has the Stop option.

[dsb.nepo]

use the command line to control SecureClient, maybe create a script

scc startsc            = starts SecureClient services
scc stopsc             = stops SecureClient services
scc restartsc          = restarts SecureClient services
scc sp                 = displays the current default security policy
scc setpolicy [on|off] = enables or disables the current default security policy
scc listprofiles       = lists all profiles
scc connect [-p] <profilename>
scc disconnect -p <profilename>

[fuzza]

Interesting... I'll have to do some experimentation with the cmdline operations, to see whether we can get a compromise. If it solves the dropout problem by running the scripts, we can probably just make batch files for "start" and "stop" and train the staff to use those to control it instead of the Services view.

Still not quite as neat as not having SecureClient interfere at all, but it'll be about the same difficulty level as before (when we didn't know about the dropout issue) so I think it'll be acceptable. I'm a bit flat out at the moment but I'll try and test them in the next week or so, and get back to you.

Thanks all,
Andrew

[fuzza]

No such luck I'm afraid...

I worked out a pair of batch files to start the service (and dial our solitary connection), and then stop it again, which seemed to work. However the dropout issue mentioned previously still happens. (I presume that was what the batch files were meant to address, since they would have no effect on the blocking...).

I did discover another data point quite by accident - it only drops if the services are set to Manual. If they are on Automatic (so they start on boot) and then Checkpoint is stopped, the dropout doesn't happen. So it would seem to be something that's happening - or not happening - on bootup.

Re the installer being non-standard, our client uses the RSA SecurID scheme - does the standard client support these as well? (I haven't had a chance to try yet.)

Any other ideas folks?

Thanks a lot,
Andrew

[mcnallym]

Yes it does, the authentication method for the user is set in the user def and on the client when you do a site wizard setup it asks you the type of auth you want and you secify the correct method for that site.

What might be worth asking about a Global Properties setting under Remote Access, VPN Advanced

SecureClient/SecureRemote behaviour when disconnected

When disconnected from the Encryption Domain traffic will be
1. Dropped
2. Sent in Clear

If you are not connected then access to an IP address that is defined in the encryption domain will be sent in the clear, if option 2 is selected.

It is possible that they have option 1 selected and so drop the traffic.

Just a thought