[vpn-help] FW: RE: No DHCP Response from Gateway

Fri Nov 12 15:41:05 CST 2010

Hi Matt,

I have been able to re-create this issue consistently.

The problem is with the local subnet.

If you have a local 192.168.0.xxx address, everything works fine - however if you have a local 192.168.1.xxx address the symptoms are as described.

What would cause this issue when all VPN traffic is tunnelled in either case and virtual adaptors are used?

Any pointers would be most appreciated.

Regards,

Ben Chamberlain
Swyddog Cefnogi Cymorth Technoleg Gwybodaeth a Chyfathrebiadau/Information and Communications Technology Support Officer
Gwasaneth Tân ac Achub Gogledd Cymru/North Wales Fire and Rescue Service
Ffôn/Telephone: 01492 564 949
Ffacs/Fax: 01492 593 956
Am archwiliad diogelwch tân yn y cartref, ffoniwch 0808 100 2863, e-bostiwch cfs at nwales-fireservice.org.uk<mailto:cfs at nwales-fireservice.org.uk> neu ymwelwch â www.gwastan-gogcymru.org.uk<http://www.gwastan-gogcymru.org.uk/>.
For a free home fire safety check, please call 0808 100 2863, e-mail cfs at nwales-fireservice.org.uk<mailto:cfs at nwales-fireservice.org.uk> or visit www.nwales-fireservice.org.uk<http://www.nwales-fireservice.org.uk/>.

From: Ben Chamberlain
Sent: 22 October 2010 11:56
To: 'mgrooms at shrew.net'; vpn-help at lists.shrew.net
Subject: FW: RE: [vpn-help] No DHCP Response from Gateway

Hi Matthew,

I hope the below can provide you with some more clues as to what is going on...

I've repeated some information for completeness.

For your information the attached documents are as follows with a brief description of which each one shows...

primary.vpn - an export of the primary VPN connection settings used (PSK, unique ID, gateway IP removed) - these same settings are used on every client.
secondary.vpn - an export of the secondary VPN connection settings used (PSK, unique ID, gateway IP removed) - these same settings are used on every client.
debug1.txt - log for LAN connection to primary VPN - taken from client2, worked OK every time for both clients.
debug2.txt - log for WIFI connection to primary VPN - taken from client2, negotiation time occurred every time for both clients.
debug3.txt - log for LAN connection to secondary VPN - taken from client2, no DHCP response from gateway every time for both clients.
debug4.txt - log for WIFI connection to secondary VPN - taken from client2, no DHCP Response from gateway every time for both clients.
primary-phase1.jpg - screenshot of primary remote gateway's phase1 settings.
primary-phase2.jpg - screenshot of primary remote gateway's phase2 settings.
secondary-phase1.jpg - screenshot of secondary remote gateway's phase1 settings.
secondary-phase2.jpg - screenshot of secondary remote gateway's phase2 settings.

Client 1 Details:

VPN Client Version: 2.1.7

Windows OS Version: Windows XP Professional SP3

LAN Adaptor: Broadcom NetXtreme 57xx Gigabit Controller

LAN Drivers: 06/03/2007 10.26.0.0

WIFI Adaptor: Intel Pro/Wireless 3945ABG

WIFI Drivers: 15/08/2010 13.3.0.137 (latest)

Client 2 Details:

VPN Client Version: 2.1.7

Windows OS Version: Windows 7 Professional

LAN Adaptor: Broadcom NetXtreme 57xx Gigabit Controller

LAN Drivers: 21/05/2010 14.2.0.5

WIFI Adaptor: Intel Pro/Wireless 3945ABG

WIFI Drivers: 26/03/2009 12.4.1.4

Local Gateway Details:

Router Make/Model: Belkin F5D8636-4 v2

Router Firmware: 2.00.20 (Oct 5 2009 17:17:19)

ISP: TalkTalk

Remote Gateway Details (for Primary VPN):

Gateway Make/Model: FortiGate 310B

Gateway OS Version: 3.00-b5298(MR6)

Remote Gateway Details (for Secondary VPN):

Gateway Make/Model: FortiGate 300A

Gateway OS Version: 3.00,build0413,070503

It's also worth noting that the route into the Primary and Secondary gateways are physically different i.e. use different ISPs, one is a 30Mb leased line, other is an 8Mb business broadband link.

So the above scenario and results is as follows:

·         Client 1 and client 2 try to connect to the primary VPN connection by LAN, which points to the primary remote gateway - result is OK every time.

·         Client 1 and client 2 try to connect to the primary VPN connection by WIFI, which points to the primary remote gateway - result is negotiation timeout everytime.

·         Client 1 and client 2 try to connect to the secondary VPN connection by LAN, which points to the secondary remote gateway - result is no DHCP response from gateway everytime.

·         Client 1 and client 2 try to connect to the secondary VPN connection by WIFI, which points to the secondary remote gateway - result is no DHCP response from gateway everytime.

The scenario described above is not an isolated occurrence. We have occurrences of this for many other people. All people have the below characteristics; for some it works with no problems, other it's a bit hit and miss, others it's never worked at all.

1.       All use ShrewSoft VPN client release 2.1.6.

2.       Use a variety of local gateways and ISPs such as TalkTalk, BTInternet, Sky, Tiscali.

3.       All use Windows XP SP3.

4.       All have Broadcom NetXtreme 57xx Gigabit Controller/ Intel Pro/Wireless 3945ABG but with differing driver versions.

5.       All use exactly the same VPN connection settings and are all trying to connect into the same remote gateways (primary and secondary).

Further information to the above scenario is that Client 1 works fine, no problems at all, at several other locations by both WIFI and LAN over the primary and secondary connections/gateways.

Furthermore, what was extremely surprising was that yesterday I tried the exact scenario again - however, client 2 was able to connect to primary via WIFI successfully on one occasion only.

To reproduce: The only way I have able to reproduce this with Client 1 (at another location where this issue does not exist by default) is by using a network bandwidth throttler. The only way to recreate the problem is to limit network upload and download to about 150Bytes, where at this point I start to get the No DHCP response and negotiation timeout messages. However at the location of people with the described problem, network speeds are much greater than this e.g. a 2Mb-8Mb broadband link with what you would expect as average/acceptable upload/download speeds.

Our thoughts: We are thinking that for some reason ShrewSoft isn't giving our FortiGate enough time to respond. What we've experienced to date has a certain timeout/latency feel to it. Our reasons for thinking this are as follows: with our previous VPN client (the Fortigate proprietary VPN software - FortiClient, which we had few VPN connection problems with) establishing the VPN connection used to take longer than with successful ShrewSoft attempts. Shrewsoft doesn't seem to 'hang around' enough before giving the described error messages in comparison to how long it sometimes used to take to establish a successful connection with the Forticlient software - it's like ShrewSoft times out on waiting for a response. Furthermore for a given client occurrence of No DHCP response from gateway, on our remote gateway logs we can see phase 1 come up, but not phase 2. So these clients hit the remote gateway ok but don't get any further than this. Our network engineers have inspected the logs are said that the cannot see any errors - it's as if the connection attempt get terminated from the client end.

Our efforts to date with no improvement:

·         Reinstallation of ShrewSoft client.

·         Upgrade of ShrewSoft client to 2.1.7.

·         Recreation of VPN connection settings.

·         Upgrade of client's network adaptor drivers to latest versions.

·         Disabling/enabling of NAT-T on the ShrewSoft client.

·         Reducing the MTU on the ShrewSoft client.

·         Disabling/enabling of DPD on the ShrewSoft client.

·         Disabling/enabling of IKE Fragmentation on the ShrewSoft client.

Any suggestions which you can make would be most appreciated - I'm here and willing to test any solutions which you may be able to offer.

Once again thanks for all of your assistance,

Best Regards,

Ben Chamberlain
Swyddog Cefnogi Cymorth Technoleg Gwybodaeth a Chyfathrebiadau/Information and Communications Technology Support Officer
Gwasaneth Tân ac Achub Gogledd Cymru/North Wales Fire and Rescue Service
Am archwiliad diogelwch tân yn y cartref, ffoniwch 0808 100 2863, e-bostiwch cfs at nwales-fireservice.org.uk<mailto:cfs at nwales-fireservice.org.uk> neu ymwelwch â www.gwastan-gogcymru.org.uk<http://www.gwastan-gogcymru.org.uk/>.
For a free home fire safety check, please call 0808 100 2863, e-mail cfs at nwales-fireservice.org.uk<mailto:cfs at nwales-fireservice.org.uk> or visit www.nwales-fireservice.org.uk<http://www.nwales-fireservice.org.uk/>.

**********************************************************************
Cyfrinachedd: Mae’r neges e-bost hon ac unrhyw ffeiliau a 
drosglwyddir gyda hi, yn breifat ac fe allent fod yn cynnwys gwybodaeth 
sy’n gyfrinachol neu’n gyfreithiol-freintiedig. Os byddwch yn derbyn 
y neges hon trwy gamgymeriad, a fyddech mor garedig â rhoi 
gwybod inni a chael gwared arni o’ch system ar unwaith.

Ymwadiad: Fe allai e-bostio trwy’r We fod yn agored i oedi, 
rhyng-gipio, peidio â chyrraedd, neu newidiadau heb eu hawdurdodi. 
Felly, nid yw’r wybodaeth a fynegir yn y neges hon yn cael cefnogaeth 
GTAGC oni bai fod cynrychiolydd awdurdodedig, yn annibynnol 
ar yr e-bost hwn, yn hysbysu ynghylch hynny. Ni ddylid gweithredu 
o ddibynnu ar gynnwys yr e-bost hwn yn unig.

Monitro: Bydd GTAGC yn monitro cynnwys e-byst at ddiben 
atal neu ddarganfod troseddau, a hynny er mwyn sicrhau diogelwch 
ein systemau cyfrifiadurol a gwirio cydymffurfiad â’n polisïau.

Gwasanaeth Tân ac Achub Gogledd Cymru 
Parc Busnes Llanelwy, Sir Ddinbych.  LL17 0JJ 
**********************************************************************
Confidentiality: This email and any files transmitted with it, are 
private and may contain confidential or legally privileged information. 
If you receive this message in error, please notify us and then 
immediately remove it from your system.

Disclaimer: Internet email may be subject to delays, interception, 
non-delivery or unauthorised alterations. Therefore, information 
expressed in this message is not endorsed by NWFRS unless 
otherwise notified by an authorised representative independent 
of this email. No action should be taken in reliance on the 
content of this email.

Monitoring: NWFRS monitors email traffic content for the purposes 
of the prevention and detection of crime, ensuring the security of 
our computer systems and checking compliance with our policies

North Wales Fire and Rescue Service
St Asaph Business Park, Denbighshire. LL17 0JJ
**********************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.shrew.net/pipermail/vpn-help/attachments/20101112/35e3f24d/attachment-0001.html>