This article applies to:
Question:
Many odd LOGOFF entries in the User Name log from IP address 169.254.x.x
Reply
Applicable to the following conditions:
- Using Tier1 authentication with the 8e6 Authenticator client (authenticat.exe)
- User workstations run in a Windows DHCP environment
For a Windows DHCP environment, some workstations may be assigned a temporary IP address in the 169.254.0.0/16 range before it receives a DHCP 10.0.0.0/8 address. Workstations can also be assigned a 169.254.x.x IP if they fail to acquire a 10 address for whatever reason.
If authenticat.exe is running during this process, the R3000 might not handle it properly and record LOGOFF attempts for those temporary IP addresse. The User Name log might look something like this:
LOGOFF, 2007-07-27 14:55:55, 169.254.100.16, p3
LOGOFF, 2007-07-27 14:58:10, 169.254.185.192, p3
LOGOFF, 2007-07-27 15:03:40, 169.254.146.14, p3
LOGOFF, 2007-07-27 15:26:55, 169.254.227.218, p3
Having too many of these LOGOFF requests going to the R3000 can cause unnecessary load issues on its authentication module.
To keep R3000 from handling these requests, you can add an extra parameter (RV) to the authenticat.exe logon script. The idea behind this is to send invalid authentication requests away from the R3000, usually to a bogus loopback address.
For example, if your virtual IP address for authentication is 10.0.0.2 and you only want to authenticate workstations in the 10.0.0.0/8 range, then the authenticat.exe command can look something like this:
start authenticat.exe RA[10.0.0.2] RV[(169.254.0.0-169.254.255.255;127.1.1.1)]
Thus, if authenticat.exe sees the source IP address as anything within the 169.254.0.0/16 range, it will send the request to 127.1.1.1 rather than the actual R3000 virtual IP address 10.0.0.2.
- This article was previously published as:
- 8e6 KB 276567
