[Vpn-help] Shrew v. 2.1.4 Openswan 2.4.6.1

[Matthew Grooms]

Stefan Bauer wrote:
> Hi,
> 
> 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
> |
> |
> |
> Internet
> |
> |
> |
> -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!
> 

Stefan,

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 91.8.45.163: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 
session
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 
error )

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 91.8.45.163: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 
session
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,

-Matthew