SecureClient and Office Mode

[pemuller]

I have a question with regards to the functionality of Office Mode. I have currently Office Mode configured and it seems to work as I understand it should work, i.e. SecureClients are provided with a "local" address as well as DNS and WINS servers when they connect it.

I do however have a problem in hotels/hotspots where my SecureClient are assigned an address that overlaps with our internal address range (encryption domain) in that SecureClient simply just doesn't start up, as it believes it is connect to the internal network.

I have seen some entries in the forum, that seem to indicate that Office Mode could solve this problem, but I simply cannot see how. Can anyone spread some light on this.

[dbedit]

Enable 'dynamic interface resolving', edit your fw object--->VPN---->VPN advanced.
If not, do a search from within Smartdasboard.
It will tell you where to find the setting.
Install policy after enabling.
Users must update their policy afterwards.
Also make sure RDP(Checkpoint no MS plz....:-) is allowed in policy from OM-pool to gtw.

[pemuller]

I still seem to have a problem, even after having made the changes proposed. If my SecureClient is assigned an address in the 10.1.1.x range (also used in our central LAN), it tries do an ARP, looking for the gateways internal address which is 10.1.1.26.

As this goes nowhere (or if it goes somehwhere, it certainly isn't to my gateway) SecureClientgives up with a message that it failed to connectto the gateway.

Is it me, or ........

[RayPesek]

Office Mode must NOT be anything used on your LAN and your LAN needs to be able to route it to the firewall.

For example, if you pick 172.16.25.0 255.255.255.0 for your Office Mode pool and your LAN default route points to the firewall internal interface, it will work. Any LAN ACLs must now allow 172.16.25.0/24, though.

Ray

[pemuller]

I'm afraid I still don't get it. Our LAN uses the subnet 10.1.0.0/20 and the gateway's Office Mode uses the subnet 10.1.80.0/20. The address of our gateways internal interface equals 10.1.1.26.

If one of my clients is located in a hotel and is assigned any address in the 10.1.0.0 address range,when trying to connect with SecureClient, it sends out an ARP asking to locate 10.1.1.26. After 10 or so attempts, it "rolls over" and declares that the gateway cannot be found.

Where do I go wrong?

[chillyjim]

Has your client check the "Status" to make sure they have an office mode address assigned?

[pemuller]

This is where I don't really see/understand how the Office Mode works. I was under the impression that the Office Mode address is assigned once the SecureClient has initiated a connection to the gateway, but in this specific case (when the client is assigned a address in the 10.1.0.0 subnet by the hotel DHCP server) SecuRemote does not initiate a connection to the gateway. It sends out a ARP request for the gateways internal address (10.1.1.26), and then gives up.

In the case where a client is assigned a non-10.1.0.0 address, they are provided with a Office Mode address once connected to the gateway.

[dsb.nepo]

it tries do an ARP, looking for the gateways internal address which is 10.1.1.26.

I'm afraid I still don't get it. Our LAN uses the subnet 10.1.0.0/20 and the gateway's Office Mode uses the subnet 10.1.80.0/20. The address of our gateways internal interface equals 10.1.1.26.

Is it possible that your topology has the internal interface as the main IP in your gateway object? This would explain the arp request to the LAN interface.
It so you have to fix this to the exernal IP (if you have a SPLAT also check the IP in /etc/hosts at the gateway sometimes CP change this if the name points to the internal interface and can be resolved via DNS)

[pemuller]

This works fine when connecting from a address other than 10.1.0.0. SecureClient finds the external address of the gateway and connects. The connection uses TCP to communicate with the gateways external interface.

The gateways "LAN" address (10.1.1.26) is included in the gateways topology and it seems that when SecureClient is provided with a DHCP address in the 10.1.0.0 address range, it believs that it is connected "inside" the LAN and tries to contact the gateway through its LAN address by sending out an ARP request.

Gateway is an IP530 running NG AI R55 HFA09 soon to be upgraded to NGX.

[mcnallym]

If the network interface of the laptop picks up an address that is in the same range as your internal network (10.1.0.0/20) then the secure client will not attempt to connect to your external IP address as it will determine that the laptop is inside your internal network.

If you look inside the userc.c file on the laptop you will all of the interfaces of the Gateway defined in there.

Office Mode works by assigning an IP address to the Virtual Network Adaptor that is installed on the SecureClient Laptop. However that IP is dynamic and requires that you connect to the gateway first.

Office Mode cannot sort out where you are connecting from a network that overlaps with your internal network as it sees you as being internal to your network already.

[pemuller]

Thank you. That confirms how I thought Office Mode works. Now to my next question.

Does there exist any documentation over how the SecureClient userc.C file works? I'm trying to develop a cut down version that only contains the address of our Exchange and SharePoint server in order to only have 2 addresses that may make SecureClient have a problem?

[mcnallym]

The normal way would be to set the encryption domain to be just the two addresses so that is all that you can reach in the encryption domain.

SecureClient references the user.c file to identify the gateway it should use and the network protected by that gateway.

Normally is pulled down from the encryption domain setting.

On NGX you can set a seperate Remote Access Domain, try setting that to just two ip addresses, update your topology and retry.

[RayPesek]

Originally Posted by mcnallym

If the network interface of the laptop picks up an address that is in the same range as your internal network (10.1.0.0/20) then the secure client will not attempt to connect to your external IP address as it will determine that the laptop is inside your internal network.

That's not accurate. I routinely use SecureClient from our plant locations with Office Mode to pick up a known Office Mode address so I can connect to the firewall to manage it. The plant IP ranges are inside the encryption domain.

Office Mode works by assigning an IP address to the Virtual Network Adaptor that is installed on the SecureClient Laptop. However that IP is dynamic and requires that you connect to the gateway first.

Getting the address does require that you connect first, but you can specify an IP address on a per-user basis by using the ipassignment.conf file.

Office Mode cannot sort out where you are connecting from a network that overlaps with your internal network as it sees you as being internal to your network already.

It can. The OM IP is tied to the virtual NIC and routed down the tunnel. The IP from the hotel is tied to the real NIC and not routed down the tunnel.

PEMuller, what version of SecureClient are you using? I would highly recommend NGX R60, but not the HFA1 Vista one. The version of SecureClient can be greater than the gateway and it will work fine. I ran SecureClient NGX R60 with an R55 HFA18 gateway for a long time. There were some Office Mode fixes in the later versions.

SecureClient will connect using whatever IP address is assigned to the firewall object in SmartView Dashboard on an R55 gateway.

Ray

[pemuller]

Originally Posted by RayPesek

That's not accurate. I routinely use SecureClient from our plant locations with Office Mode to pick up a known Office Mode address so I can connect to the firewall to manage it. The plant IP ranges are inside the encryption domain.

This is something that works for me to if I'm located inside my encryption domain, but my SecureClient connects to the firewalls internal (LAN) interface and not the external one.

I have managed to "cobble" together a userc.C file with only 4 host addresses in it, and with the limited testing I have managed to do, this seems to work. This way I have at least reduced the chance of an address clash by several 100%.

This new userc.C file has however a side effect. When connected to my internal LAN, I'm not able to access these 4 hosts if my SecureClient is started (icon in bottom right hand corner) but not connected. In order to access these 4 hosts, I either have to stop the two SecureClient services or connect with SecureClient as described at the beginning of this entry.

So, in general, I guess my problem is more or less resolved. I will only encounter a problem if I'm assigned one of these four addresses, and this would be really bad luck.

[RayPesek]

Unfortunately the first time a topology update comes down, the userc.c file will get replaced with the standard one.

You shouldn't have to be doing this, though.

This new userc.C file has however a side effect. When connected to my internal LAN, I'm not able to access these 4 hosts if my SecureClient is started (icon in bottom right hand corner) but not connected. In order to access these 4 hosts, I either have to stop the two SecureClient services or connect with SecureClient as described at the beginning of this entry.

This also should not be happening. There is a property in userc.c to send in the clear while in the encryption domain than can be set to true.

How do your default SecureClient policy rules look, the ones for "all users@any"? You should have those defined so you can access your internal subnets with "accept" rules in the outbound section.

Ray