[vpn-help] Shrew 2.5.1 and Draytek Vigor 2710 VPN

[Matthew Grooms]

On 7/24/2010 3:38 PM, Karnin wrote:
> Dear list members,
> that's my novice report to vpn-help list, so please be patient with me
> :)
>
> ## Client:
> Windows XP Sp3
> Shrew VPN client version = 2.1.5
> Fritz!Box 7170 with DYNDNS.ORG-dynamic IP, ADSL
> with Firmware 29.04.80
> Client-subnet 192.168.112.0
>
> ## Host:
> Draytek Vigor 2710 with DYNDNS.ORG-dynamic IP, ADSL
> with Firmware 3.3.5 Standard for AnnexB
> Host-subnet 192.168.215.0
>
> ## Setup according to:
> http://draytek.de/Beispiele/VPN/ShrewSoft_Client.pdf
>
> ## Problem:
> esp-AES-Tunnel/Auth will be established without any problem.
> Draytek Router/Gateway 192.168.215.1 at host side answers to ping,
> router's admin-page can be accessed by IP adress =>  working.
> A Synology diskstation DS207 (linux system!) 192.168.215.100 can be
> pinged and accessed at host side =>  working.
> BUT:
> Not pingable or accessible are the windows machines in subnet
> 192.168.215.0:
> -Windows 2003 Server Standard
> -Windows XP Sp3
> -Windows 98SE (only terminalclient)
>
> Firewalls are switched off for exploration purposes.
>
> Problem is reproducable on different Windows XP Sp3-clients (Subnet
> 192.168.112.0).
>
> Really mysterious......
>
> Any hint for us?
>

Are you trying to ping using the IP address or the host name? NetBios 
name resolution can be tricky over VPN connections. In any case, the 
best way to troubleshoot issues like this is to follow the packet flow 
between the client and the target host machine. For example, the client 
has bytes in/out for security associations that can be examined using 
the VPN trace utility. If you are pinging a device on the remote end of 
the connection, you should see the bytes increase for the outbound SA ( 
listed as <CLIENT IP> -> <GATEWAY IP> ) at the very least. This means 
its taking the outbound packets and tunneling them to the gateway. The 
next step would be to check the inbound SA on the gateway to see if the 
bytes or packet count is increasing. This proves that the packets are 
being received and processed by the gateway. Next, use a packet capture 
utility on the host you are trying to ping to see if the ICMP packets 
are arriving and if the host is sending a response. Then you trace the 
packets back the other direction by checking the outbound SA on the 
gateway and the inbound SA on the client. It should be obvious where the 
communication breakdown occurs.

Hope this helps,

-Matthew