I appreciate the response. I thought I included both phases. I'll put more of the log in this message. Thanks for any help. (I also think it's stupid Watchguard switched over to Shrew because it's lazy on their part!)
11/11/30 21:03:33 ii : phase1 sa established 11/11/30 21:03:33 ii : ##.###.###.##:4500 <-> 192.168.1.21:4500 11/11/30 21:03:33 ii : bd0b5c039a760147:e5d89fd56d79cb3b 11/11/30 21:03:33 ii : sending peer INITIAL-CONTACT notification 11/11/30 21:03:33 ii : - 192.168.1.21:4500 -> ##.###.###.##:4500 11/11/30 21:03:33 ii : - isakmp spi = bd0b5c039a760147:e5d89fd56d79cb3b 11/11/30 21:03:33 ii : - data size 0 11/11/30 21:03:33 >> : hash payload 11/11/30 21:03:33 >> : notification payload 11/11/30 21:03:33 == : new informational hash ( 20 bytes ) 11/11/30 21:03:33 == : new informational iv ( 8 bytes ) 11/11/30 21:03:33 >= : cookies bd0b5c039a760147:e5d89fd56d79cb3b 11/11/30 21:03:33 >= : message 9bdd0865 11/11/30 21:03:33 >= : encrypt iv ( 8 bytes ) 11/11/30 21:03:33 == : encrypt packet ( 80 bytes ) 11/11/30 21:03:33 == : stored iv ( 8 bytes ) 11/11/30 21:03:33 -> : send NAT-T:IKE packet 192.168.1.21:4500 -> ##.###.###.##:4500 ( 116 bytes ) 11/11/30 21:03:33 DB : phase2 not found 11/11/30 21:03:33 <- : recv IKE packet ##.###.###.##:500 -> 192.168.1.21:500 ( 352 bytes ) 11/11/30 21:03:33 DB : phase1 found 11/11/30 21:03:33 ww : initiator port values should only float once per session 11/11/30 21:03:33 ii : processing phase1 packet ( 352 bytes ) 11/11/30 21:03:33 !! : phase1 packet ignored, resending last packet ( phase1 already mature ) 11/11/30 21:03:33 -> : resend 1 phase1 packet(s) [0/2] 192.168.1.21:4500 -> ##.###.###.##:4500 11/11/30 21:03:33 <- : recv IKE packet ##.###.###.##:500 -> 192.168.1.21:500 ( 352 bytes ) 11/11/30 21:03:33 DB : phase1 found 11/11/30 21:03:33 ww : initiator port values should only float once per session 11/11/30 21:03:33 ii : processing phase1 packet ( 352 bytes ) 11/11/30 21:03:33 !! : phase1 packet ignored, resending last packet ( phase1 already mature ) 11/11/30 21:03:33 -> : resend 1 phase1 packet(s) [1/2] 192.168.1.21:4500 -> ##.###.###.##:4500 11/11/30 21:03:33 <- : recv NAT-T:IKE packet ##.###.###.##:4500 -> 192.168.1.21:4500 ( 116 bytes ) 11/11/30 21:03:33 DB : phase1 found 11/11/30 21:03:33 ii : processing config packet ( 116 bytes ) 11/11/30 21:03:33 DB : config not found 11/11/30 21:03:33 DB : config added ( obj count = 1 ) 11/11/30 21:03:33 == : new config iv ( 8 bytes ) 11/11/30 21:03:33 =< : cookies bd0b5c039a760147:e5d89fd56d79cb3b 11/11/30 21:03:33 =< : message d879ecbe 11/11/30 21:03:33 =< : decrypt iv ( 8 bytes ) 11/11/30 21:03:33 == : decrypt packet ( 116 bytes ) 11/11/30 21:03:33 <= : trimmed packet padding ( 2 bytes ) 11/11/30 21:03:33 <= : stored iv ( 8 bytes ) 11/11/30 21:03:33 << : hash payload 11/11/30 21:03:33 << : attribute payload 11/11/30 21:03:33 == : configure hash_i ( computed ) ( 20 bytes ) 11/11/30 21:03:33 == : configure hash_c ( computed ) ( 20 bytes ) 11/11/30 21:03:33 ii : configure hash verified 11/11/30 21:03:33 ii : - xauth username 11/11/30 21:03:33 ii : - xauth password 11/11/30 21:03:33 ii : received basic xauth request - Please Enter Your User Name and Password : 11/11/30 21:03:33 ii : - standard xauth username 11/11/30 21:03:33 ii : - standard xauth password 11/11/30 21:03:33 ii : sending xauth response for dfolmer 11/11/30 21:03:33 >> : hash payload 11/11/30 21:03:33 >> : attribute payload 11/11/30 21:03:33 == : new configure hash ( 20 bytes ) 11/11/30 21:03:33 >= : cookies bd0b5c039a760147:e5d89fd56d79cb3b 11/11/30 21:03:33 >= : message d879ecbe 11/11/30 21:03:33 >= : encrypt iv ( 8 bytes ) 11/11/30 21:03:33 == : encrypt packet ( 87 bytes ) 11/11/30 21:03:33 == : stored iv ( 8 bytes ) 11/11/30 21:03:33 -> : send NAT-T:IKE packet 192.168.1.21:4500 -> ##.###.###.##:4500 ( 124 bytes ) 11/11/30 21:03:33 DB : config resend event scheduled ( ref count = 2 ) 11/11/30 21:03:33 <- : recv NAT-T:IKE packet ##.###.###.##:4500 -> 192.168.1.21:4500 ( 116 bytes ) 11/11/30 21:03:33 DB : phase1 found 11/11/30 21:03:33 ii : processing config packet ( 116 bytes ) 11/11/30 21:03:33 DB : config found 11/11/30 21:03:33 =< : cookies bd0b5c039a760147:e5d89fd56d79cb3b 11/11/30 21:03:33 =< : message d879ecbe 11/11/30 21:03:33 =< : decrypt iv ( 8 bytes ) 11/11/30 21:03:33 == : decrypt packet ( 116 bytes ) 11/11/30 21:03:33 !! : validate packet failed ( reserved value is non-null ) 11/11/30 21:03:33 !! : config packet ignored ( packet decryption error ) 11/11/30 21:03:33 <- : recv NAT-T:IKE packet ##.###.###.##:4500 -> 192.168.1.21:4500 ( 116 bytes ) 11/11/30 21:03:33 DB : phase1 found -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kevin VPN Sent: Thursday, December 01, 2011 9:49 PM To: [email protected] Subject: Re: [vpn-help] Shrew not connecting to Watchguard 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: [email protected] > [mailto:[email protected]] On Behalf Of Greg Ledford > Sent: Wednesday, November 30, 2011 9:15 PM > To: '[email protected]' > 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. _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help _______________________________________________ vpn-help mailing list [email protected] http://lists.shrew.net/mailman/listinfo/vpn-help
