[Vpn-help] Shrew v. 2.1.4 Openswan 184.108.40.206
mgrooms at shrew.net
Thu Nov 20 13:46:14 CST 2008
Stefan Bauer wrote:
> i step in a problem during setup of a roadwarrior vpn gateway with
> shrew 2.1.4 client on winxp.
> RW 192.168.0.111
> -NAT-BOX-192.168.0.23 / external-NAT-BOX ip
> -NAT-BOX- 10.8.0.254 / external-natbox-ip
> IPSEC-GW with 10.8.0.1 / 10.10.0.1 (ipsec0 is bind to 10.10.0.1)
> Roadwarrior-Pool 192.168.100.0/24
> Please see the shrew log's attached:
> thanks in advance!
As far as I can tell, the client appears to be operating as it should
be. My guess is that there is some sort of configuration mismatch
between the client and the gateway. In your log output, the client is
using main mode ( identity protect ) and the first four packets in the
exchange are being processed rather slowly, but without issue.
08/11/20 12:33:08 -> : send IKE packet ...
08/11/20 12:33:09 <- : recv IKE packet ...
08/11/20 12:33:11 -> : send IKE packet ...
08/11/20 12:33:14 <- : recv IKE packet ...
The problem occurs when the client sends the fifth exchange packet which
contains the identification and certificate information.
08/11/20 12:33:15 >> : identification payload
08/11/20 12:33:15 >> : certificate payload
08/11/20 12:33:15 == : phase1 hash_i ( computed ) ( 20 bytes )
08/11/20 12:33:16 >> : signature payload
08/11/20 12:33:16 >= : cookies 80f125fcb8a977d7:b0fec90cbc5f28b2
08/11/20 12:33:16 >= : message 00000000
08/11/20 12:33:16 >= : encrypt iv ( 8 bytes )
08/11/20 12:33:16 == : encrypt packet ( 1636 bytes )
08/11/20 12:33:16 == : stored iv ( 8 bytes )
08/11/20 12:33:16 DB : phase1 resend event canceled ( ref count = 1 )
08/11/20 12:33:16 -> : send NAT-T:IKE packet ...
First of all, the gateway is sending a new notification packet using UDP
port 500 after we have switched to port 4500 which, I believe, is a
violation of the RFC. But this is quite likely a result of the failed
negotiation. Secondly, the notification message is encrypted.
08/11/20 12:33:20 <- : recv IKE packet 220.127.116.11:500 ->
192.168.0.111:500 ( 68 bytes )
08/11/20 12:33:20 DB : phase1 found
08/11/20 12:33:20 ww : initiator port values should only float once per
08/11/20 12:33:20 ii : processing informational packet ( 68 bytes )
08/11/20 12:33:20 == : new informational iv ( 8 bytes )
08/11/20 12:33:20 =< : cookies 80f125fcb8a977d7:b0fec90cbc5f28b2
08/11/20 12:33:20 =< : message faa76d62
08/11/20 12:33:20 =< : decrypt iv ( 8 bytes )
08/11/20 12:33:20 == : decrypt packet ( 68 bytes )
08/11/20 12:33:20 !! : validate packet failed ( reserved value is non-null )
08/11/20 12:33:20 !! : informational packet ignored ( packet decryption
We can't decrypt this message but I'm not sure if thats really an issue
at this point since its probably also a result of failed negotiations.
After the notification, we receive a re-transmission of the 4th packet
in the exchange which is consistent with the notion that it rejected a
parameter sent in our fifth packet.
08/11/20 12:33:24 <- : recv IKE packet 18.104.22.168:500 ->
192.168.0.111:500 ( 484 bytes )
08/11/20 12:33:24 DB : phase1 found
08/11/20 12:33:24 ww : initiator port values should only float once per
08/11/20 12:33:24 ii : processing phase1 packet ( 484 bytes )
08/11/20 12:33:24 =< : cookies 80f125fcb8a977d7:b0fec90cbc5f28b2
08/11/20 12:33:24 =< : message 00000000
08/11/20 12:33:24 << : ignoring duplicate key excahnge payload
08/11/20 12:33:24 !! : unprocessed payload data
The best advice I can give you is to examine the OpenSWAN log output on
the Linux host. My hunch is that it failed to validate the certificate
for some reason, sends a notification to that effect and re-transmits
the 4th packet. All of this seems very reasonable. Sorry I can't offer a
more specific solution to your problem :/
Hope this helps,
More information about the vpn-help