[vpn-help] Shrew not connecting to Watchguard

[Kevin VPN]

On 12/01/2011 10:34 PM, Greg Ledford wrote:
> No one has ANY ideas on this? Seems this is a reoccurring issue with computers using wireless cards. I really need a solution for this. Watchguard switched over to this Shrew client and they don't directly support it. There is no other outlet for help!
>
> From: vpn-help-bounces at lists.shrew.net [mailto:vpn-help-bounces at lists.shrew.net] On Behalf Of Greg Ledford
> Sent: Wednesday, November 30, 2011 9:15 PM
> To: 'vpn-help at lists.shrew.net'
> Subject: [vpn-help] Shrew not connecting to Watchguard
>
> Hello. I hope I'm posting this question properly. We have a Watchguard firewall that is working properly with 50+ users. I have one that is on a Windows 7 x64 computer running Shrew VPN 2.2.0 beta 2 that isn't working at all. Here is the info from the iked.log in case any of this helps:
>
> 11/11/30 21:07:57 DB : phase1 found
> 11/11/30 21:07:57 ii : processing informational packet ( 84 bytes )
> 11/11/30 21:07:57 == : new informational iv ( 8 bytes )
> 11/11/30 21:07:57 =<  : cookies bd0b5c039a760147:e5d89fd56d79cb3b
> 11/11/30 21:07:57 =<  : message c6fab736
> 11/11/30 21:07:57 =<  : decrypt iv ( 8 bytes )
> 11/11/30 21:07:57 == : decrypt packet ( 84 bytes )
> 11/11/30 21:07:57<= : stored iv ( 8 bytes )
> 11/11/30 21:07:57<<  : hash payload
> 11/11/30 21:07:57<<  : notification payload
> 11/11/30 21:07:57 == : informational hash_i ( computed ) ( 20 bytes )
> 11/11/30 21:07:57 == : informational hash_c ( received ) ( 20 bytes )
> 11/11/30 21:07:57 ii : informational hash verified
> 11/11/30 21:07:57 ii : received peer DPDV1-R-U-THERE-ACK notification
> 11/11/30 21:07:57 ii : - 65.196.130.98:4500 ->  192.168.1.21:4500
> 11/11/30 21:07:57 ii : - isakmp spi = bd0b5c039a760147:e5d89fd56d79cb3b
> 11/11/30 21:07:57 ii : - data size 4
> 11/11/30 21:07:57 ii : DPD ARE-YOU-THERE-ACK sequence 2e87e32b accepted
> 11/11/30 21:07:57 ii : next tunnel DPD request in 15 secs for peer 65.196.130.98:4500
> 11/11/30 21:07:57<- : recv NAT-T:IKE packet 65.196.130.98:4500 ->  192.168.1.21:4500 ( 84 bytes )
> 11/11/30 21:07:57 DB : phase1 found
> 11/11/30 21:07:57 ii : processing informational packet ( 84 bytes )
> 11/11/30 21:07:57 == : new informational iv ( 8 bytes )
> 11/11/30 21:07:57 =<  : cookies bd0b5c039a760147:e5d89fd56d79cb3b
> 11/11/30 21:07:57 =<  : message c6fab736
> 11/11/30 21:07:57 =<  : decrypt iv ( 8 bytes )
> 11/11/30 21:07:57 == : decrypt packet ( 84 bytes )
> 11/11/30 21:07:57<= : stored iv ( 8 bytes )
> 11/11/30 21:07:57<<  : hash payload
> 11/11/30 21:07:57<<  : notification payload
> 11/11/30 21:07:57 == : informational hash_i ( computed ) ( 20 bytes )
> 11/11/30 21:07:57 == : informational hash_c ( received ) ( 20 bytes )
> 11/11/30 21:07:57 ii : informational hash verified
> 11/11/30 21:07:57 ii : received peer DPDV1-R-U-THERE-ACK notification
> 11/11/30 21:07:57 ii : - 65.196.130.98:4500 ->  192.168.1.21:4500
> 11/11/30 21:07:57 ii : - isakmp spi = bd0b5c039a760147:e5d89fd56d79cb3b
> 11/11/30 21:07:57 ii : - data size 4
> 11/11/30 21:07:57 ii : DPD ARE-YOU-THERE-ACK sequence 2e87e32b accepted
> 11/11/30 21:07:57 ii : next tunnel DPD request in 15 secs for peer 65.196.130.98:4500
>

Hi Greg,

Unfortunately, you haven't provided enough of the iked.log for us to 
help much.  All I see are phase1 packets, and everything is hunky dory 
with them. I don't know if the phase2 negotiations completed 
successfully.  If phase2 failed, that would explain why the client is 
not working.

Any chance you can provide the complete log?  Feel free to anonymize IPs 
and usernames as appropriate.

Interesting that Watchguard has switched to this client.  I'll bet 
they're not paying to support its development.  That's unfortunate since 
it costs a great deal to get signed Windows drivers and the project 
can't really afford to do it often, which is part of the reason that the 
2.2.0 code is still beta.