1 - They do not get a DNS Suffix. an ipconfig /all reveals they have
a valid IP address, correct DNS info, but the dns suffix field is
blank.
2 - they get an incorrect route placed in thier routing table.
Our internal network is set to use 192.168.200.x/20, DHCP is set to
hand out addresses to all clients (VPN and otherwise) starting at
201.1/20. Local clients are fine and DHCP works correctly, however;
VPN clients are put on 201.x/24 and thus cannot access any resources
on 200.x range.
Configuration of DHCP has not changed, only ISA 2004 STD to 2006 Std.
Any thoughts or assistance would be greatly appreciated
Thanks,
Michael
http://support.microsoft.com/kb/232703/en-us
Note that ISA enforces a 5-second delay in updating its internal routing
table after a VPN client connects to control the CPU load (routing table
updates are *expensive*).
This may interfere with a client getting the additional information that is
supplied in the DHCP Inform req.resp cycle, since these occur almost
immediately after the connection is completed.
There is a previous thread in this same NG subj: "DHCP Request
SPOOFING_PACKET_DROPPED" that includes the process you should follow to
resolve the DHCP Inform issue *if and only if* you see ISA rejecting DHCP
traffic from VPN clients with a "SPOOFING_PACKET_DROPPED" status.
This change is still getting regression testing, so you should use it with
care.
Note: Do Not set that value lower than 1000 (0x3e8) (1 second)
--
Jim Harrison (ISA SE)
This posting implies no warranty and confers no rights.
<stuff...@gmail.com> wrote in message
news:1171906233.5...@a75g2000cwd.googlegroups.com...
I'll look at that other suggestion as I have seen warning bangs in the
eventlog with the spoofing warning.
Thank you.
On Feb 19, 11:28 am, "Jim Harrison \(ISA SE\)"
<jmh...@online.microsoft.com> wrote:
> 1.http://support.microsoft.com/kb/200211
> 2.http://support.microsoft.com/kb/138238
>
> http://support.microsoft.com/kb/232703/en-us
>
> Note thatISAenforces a 5-second delay in updating its internal routing
> table after aVPNclient connects to control the CPU load (routing table
> updates are *expensive*).
> This may interfere with a client getting the additional information that is
> supplied in the DHCP Inform req.resp cycle, since these occur almost
> immediately after the connection is completed.
> There is a previous thread in this same NG subj: "DHCP Request
> SPOOFING_PACKET_DROPPED" that includes the process you should follow to
> resolve the DHCP Inform issue *if and only if* you seeISArejecting DHCP
> traffic fromVPNclients with a "SPOOFING_PACKET_DROPPED" status.
> This change is still getting regression testing, so you should use it with
> care.
> Note: Do Not set that value lower than 1000 (0x3e8) (1 second)
> --
> Jim Harrison (ISASE)
>
> This posting implies no warranty and confers no rights.
>
> <stuff4mi...@gmail.com> wrote in message
>
> news:1171906233.5...@a75g2000cwd.googlegroups.com...
> Good morning.
> I've upgraded ourISA2004 firewall toISA2006.VPNis working and clients can connect however two things occur if
> they get addresses from DHCP:
>
> 1 - They do not get a DNS Suffix. an ipconfig /all reveals they have
> a valid IP address, correct DNS info, but the dns suffix field is
> blank.
>
> 2 - they get an incorrect route placed in thier routing table.
> Our internal network is set to use 192.168.200.x/20, DHCP is set to
> hand out addresses to all clients (VPNand otherwise) starting at
> 201.1/20. Local clients are fine and DHCP works correctly, however;VPNclients are put on 201.x/24 and thus cannot access any resources
> on 200.x range.
>
> Configuration of DHCP has not changed, onlyISA2004 STD to 2006 Std.
So this appears to be an accurate diagnosis, however; that post you
gave me isn't helpful.
the key that it references is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\RAT\Stingray\Debug\FWSRV]
"FWS_PNP_IPHELPER_QUITE_PERIOD"=dword:000005dc
There is no HKLM\Software\Microsoft\RAT.
and there is no Stingray section under HKLM\Software\Microsoft\RAS
I've also searched the registry for FWSRV, there the is no instance
with a related FWS_PNP_IPHELPER_QUIET(or Quite)_PERIOD value.
Please let me know if you have the correct reg path for this fix.
Thanks,
> > Michael- Hide quoted text -
>
> - Show quoted text -
--
Jim Harrison (ISA SE)
This posting implies no warranty and confers no rights.
<stuff...@gmail.com> wrote in message
news:1171924973.2...@v45g2000cwv.googlegroups.com...