[Swan] My test in aggressive mode running Shrew VPN client

[Philippe Vouters]

Dear Elison,

I am running the configuration I fully describe at 
http://vouters.dyndns.org/tima/Linux-Libreswan-Shrew-VPN-Testing_PAM_XAUTH_DHCP_with_Shrew.html. 
Precisely "dhcp over ipsec" + Mutual RSA + XAUTH.

The only two differences with what I actually run and what I describe 
are plutodebug=control to best match your Libreswan traces and 
xauthby=file to take into account a change I recently brought to XAUTH. 
I detail the relevant steps of Libreswan which show how and when we 
match and how and when we no longer match.

Your Libreswan trace show:
Jan 22 18:00:03 elisonniven pluto[24093]: "jun" #3: STATE_AGGR_R1: sent 
AR1, expecting AI2
Jan 22 18:00:03 elisonniven pluto[24093]: | modecfg pull: noquirk 
policy:push not-client
Jan 22 18:00:03 elisonniven pluto[24093]: | phase 1 is done, looking for 
phase 2 to unpend
Jan 22 18:00:03 elisonniven pluto[24093]: | complete state transition 
with STF_INLINE
Jan 22 18:00:03 elisonniven pluto[24093]: | complete state transition 
with STF_INLINE
Jan 22 18:00:03 elisonniven pluto[24093]: | * processed 0 messages from 
cryptographic helpers


My Libreswan trace show:
Jan 23 00:20:05 victor pluto[11580]: "Vladimir_RSA_XAuth_DHCP"[1] 
192.168.1.5 #1: STATE_AGGR_R1: sent AR1, expecting AI2
Jan 23 00:20:05 victor pluto[11580]: | modecfg pull: quirk-poll 
policy:push not-client
Jan 23 00:20:05 victor pluto[11580]: | phase 1 is done, looking for 
phase 2 to unpend
Jan 23 00:20:05 victor pluto[11580]: | complete state transition with 
STF_INLINE
Jan 23 00:20:05 victor pluto[11580]: | complete state transition with 
STF_INLINE
Jan 23 00:20:05 victor pluto[11580]: | * processed 0 messages from 
cryptographic helpers

So far match.

Your Libreswan trace:

Jan 22 18:00:03 elisonniven pluto[24093]: | *received 100 bytes from 
10.103.2.75:500 on p18p1 (port=500)
Jan 22 18:00:03 elisonniven pluto[24093]: |  processing version=1.0 
packet with exchange type=ISAKMP_XCHG_AGGR (4)
Jan 22 18:00:03 elisonniven pluto[24093]: | ICOOKIE:  77 69 66 f7 66 35 
b1 a7
Jan 22 18:00:03 elisonniven pluto[24093]: | RCOOKIE:  b3 ec 0a ee 8c 8d 
52 1d
Jan 22 18:00:03 elisonniven pluto[24093]: | state hash entry 9
Jan 22 18:00:03 elisonniven pluto[24093]: | v1 peer and cookies match on 
#3, provided msgid 00000000 vs 00000000
Jan 22 18:00:03 elisonniven pluto[24093]: | v1 state object #3 found, in 
STATE_AGGR_R1
Jan 22 18:00:03 elisonniven pluto[24093]: | processing connection jun
Jan 22 18:00:03 elisonniven pluto[24093]: "jun" #3: packet rejected: 
should have been encrypted
Jan 22 18:00:03 elisonniven pluto[24093]: "jun" #3: sending notification 
INVALID_FLAGS to 10.103.2.75:500
Jan 22 18:00:03 elisonniven pluto[24093]: | sending 40 bytes for 
notification packet through p18p1:500 to 10.103.2.75:500 (using #3)
Jan 22 18:00:03 elisonniven pluto[24093]: | * processed 0 messages from 
cryptographic helpers


My Libreswan trace:
Jan 23 00:20:05 victor pluto[11580]: | *received 1404 bytes from 
192.168.1.5:500 on eth0 (port=500)
Jan 23 00:20:05 victor pluto[11580]: |  processing version=1.0 packet 
with exchange type=ISAKMP_XCHG_AGGR (4)
Jan 23 00:20:05 victor pluto[11580]: | ICOOKIE:  72 51 cf 9d  58 29 41 16
Jan 23 00:20:05 victor pluto[11580]: | RCOOKIE:  e8 53 b4 1a  01 66 8c df
Jan 23 00:20:05 victor pluto[11580]: | state hash entry 4
Jan 23 00:20:05 victor pluto[11580]: | v1 peer and cookies match on #1, 
provided msgid 00000000 vs 00000000
Jan 23 00:20:05 victor pluto[11580]: | v1 state object #1 found, in 
STATE_AGGR_R1
Jan 23 00:20:05 victor pluto[11580]: | processing connection 
Vladimir_RSA_XAuth_DHCP[1] 192.168.1.5

In summary I cannot get your error sequence with Sghrew VPN Client.
Your error sequence is:
Jan 22 18:00:03 elisonniven pluto[24093]: "jun" #3: packet rejected: 
should have been encrypted
Jan 22 18:00:03 elisonniven pluto[24093]: "jun" #3: sending notification 
INVALID_FLAGS to 10.103.2.75:500
Jan 22 18:00:03 elisonniven pluto[24093]: | sending 40 bytes for 
notification packet through p18p1:500 to 10.103.2.75:500 (using #3)

As a possible conclusion there is either a Netscreen configuration 
mismatch with Libreswan or more likely another bug inside Netscreen.

-- 
Philippe Vouters (Fontainebleau/France)
URL: http://vouters.dyndns.org/
SIP: sip:Vouters at sip.linphone.org