Secure Client and ipassignment.conf

[jcamillo]

I have a problem with using office mode. I would like my users to get different IP information. For example I want some users to only get an IP and not DNS and some users to get an IP address and DNS.

I have been trying to use the file ipassignment.conf located on fw mod $FWDIR/conf directory. I have been editing the file with VI and when I run the verifier it checks and there are no errors. when I logon to SC I dont recieve the IP address I specified in the IPassignment file.

I have tried different formats and also rebooting, cprestarting, pushing policy and still no luck.

I also checked om_prevent_ippool_nat_for_users in objects C to true.

I am currently running on my mangement R60 on win 2003 and FW module is running R55 on Nokia 3.8

[stuartgreen]

you're not alone with this. I've been trying to get this working for about a week now and it's just not showing any love!

tried all sorts but the ipassignment.conf just will not allocate ip's on a per user basis.

and while i'm ranting about office mode...
1) It doesn't like getting addresses from DHCP servers
2) If you set it to allocate IP's from a defined network (note you can't specify a range on an existing network!) and then change that network range it will still allocate to the address range before it was changed!
3) It has a bad temper. Sometimes it works - sometimes it will let you authenticate then not connect for no apparant reason. Grrrr...

has anyone had any joy with officemode and getting an IP from either the ipassignment.conf file or from dhcp server (anything really, or the appliance is going to be thrown into the car park to think about what its done... :) )

[smithj]

I have 1100+ SecureClient users all using OfficeMode, and no problems,
but I'm not using either DHCP or the ipassignment.conf file, and am back
on FP3. OfficeMode has made a huge positive difference to my remote
users, as they frequent hotels and customer sites that tend to use the
same IP address range as our corporate network. They used to be dead
in the water, but with OfficeMode they get an IP address pushed down
from the firewall and they get connected successfully.

[jrdld]

We also have Office Mode working fine, using ipassignment.conf to assign IP pools and DNS settings to user groups for about 100 users. We use NG FP3 with AI on Nokia.

Maybe you could post an anonymised version of your ipassignment.conf. I recall that I had some problems back at the start, so maybe seeing your file would jog my memory as to how I fixed it. I do remember that it verified ok even when it didn't actually work.

JR

[jrdld]

I remembered what we did:

1. On the Gateway object, under VPN, VPN Advanced, we enabled Dynamic Interface Resolution for SecuRemote/SecureClient upon tunnel initialization. Prior to that Office mode would not work at all.

2. After that the gateway didn't seem to recognise the name of the firewall in the Module column of the ipassignment.conf, so now we just use *

We also found that you need to do a cpstop/cpstart to get it to pick up the changes to the ipassignment.conf. At least that's the case on the Nokia with R55/AI.

JR

[algray]

First off, sorry to drag this up again! i am having the same problem as jcamillo (and it seems a few others too!).

I only need to add a couple of users to the ipassignment.conf file as the IP pool setup via the management station covers the majority of users. I have been using myself as a test subject, but it doesnt seem to be working. I have tried using 'cpmodule' and * as the gateway with a series of cprestarts as each change is made - but no joy. I also get no errors detected when running vpn ipafile_check ipassignment.conf detail/warn

As i am receiving the same IP address everytime, could my user be cached somehow by the firewall? If so, can i reset it? I will try setting up a new user account and see if that works, but in the meantime, if any one has any other ideas i would be very greatfull!

For info - i am running CP SecurePlatform version NG R55

Many thanks

Alex

[melipla]

Your post prompted me to run some tests on ipassignment.conf (its been on my list of things to try for a while). I'm using R60 HFA3 for managmenet server and my two cluster members. I was able to get it working by setting up the ipassignment on each cluster member, using the cluster object's name as the gateway. My secure client had previously been assigned an OM IP address & it's lease hadn't expired yet, so I had to remove that address from my secure client machine before I was assigned my new address--it sounds like this is what you need. In order to do this, I stopped my Secure Client, opened regedit and remove the following registry folder:

My Computer\HKEY_LOCAL_MACHINE\SOFTWARE\CheckPoint\Se cuRemote\5.0\OM\

The OM folder contains entries for each gateway & what IP address it assigned to you last. Everytime you reconnect (seemingly even if the lease period has expired) secure client will try to assign that IP address to you.

Also, changes to the ipassignment.conf file are not active until the policy is pushed.

Once you set up the ipassignemnt.conf, verify it's config with this splat command: vpn ipafile_check ipassignment.conf detail

There is a note in the R60 VPN-1 documentation stating that "However, when the Office Mode per Site
feature is in use, the IP-per-user feature cannot be implemented.". The ipassignment.conf is the "IP-per-user" feature referenced. Why you can't do this with OM per Site I don't know....

HTH

[algray]

Good stuff Melipla!

I will try removing the OM directory in my registry and see if that helps... there may be a period of trial and error again, as i am still not sure if i have structured my ipassignment.conf file entries correctly. But I will post on here with my findings regardless of the outcome.

Alex

[RayPesek]

"2) If you set it to allocate IP's from a defined network (note you can't specify a range on an existing network!) and then change that network range it will still allocate to the address range before it was changed!"

Correct. There is an SK article on this that says you have to reboot the enforcement module if you change the defined network for Office Mode.

"Correct" as in "that's the way it works." Not necessarily the most user-friendly behavior, though.

We use certificates for authentication and noticed that the virtual SecureClient MAC address is somehow tied to all of this. If I have two certificates on my computer, one in ipassignment.,conf and one not, and I connect with the "not" one, I have to wait fifteen minutes to connect with the ipassignment.conf one. If I try to connect earlier, SmartCenter shows the IP address is already in use in the log.

On R55, you have to push the policy to get changes to ipassignment.conf to work.

DO NOT set the lease time longer than fifteen minutes! This setting is tied to other things somehow and setting it longer than the default messes up other stuff, although I can't remember what. There is now an SK article on this as well. I had reset it to one day and caused all kinds of problems (on R55).

If you get no erriors with "vpn ipafile_check", you should be good to go. Note that this file MUST be copied to the enforcement module; you cannot modify the one on the SmartCenter and have it pushed out. (I saw you did this; the comment is for future readers).

HTH,

Ray

[Jerry Dvoulety]

I have ipassignment.conf working like a dream. What I found was that for general users I setup an ip pool and initially I tried to use ip addresses of the same pool for ipassignment.conf file. What I found in the end is that the range used for your ipassignment.conf file must not be in use by the ip pool or anything else. Once I changed this ipassigment.conf works like a dream

[RayPesek]

Originally Posted by Jerry Dvoulety

What I found in the end is that the range used for your ipassignment.conf file must not be in use by the ip pool or anything else. Once I changed this ipassigment.conf works like a dream

It's a good thing I never read that SK article that says it must be different from the IP Pool before I went and did it successfully. :-)

The trick appears to be that the gateway hands out IP addresses from the IP Pool starting with .1 and going up sequentially. I allocated my few ipassignmentconf addresses starting with .245, which never gets reached by the sequential hand out process.

Lucked out again,

Ray

[algray]

well i did find out that you mustn't use the same ip range in ipassignment.conf as the ip pool quite early on, but fell flat on my face by missing the fact that i needed to use the full DN rather than simple user name!

As soon as i put the DN in the ipassignment.conf, it worked a treat! RTFM saved the day there! :)