[Openswan Users] Not passing the "STATE_QUICK_I1: initiate" /NO_PROPOSAL_CHOSEN

[Pawel Osiczko]

Hi Peter,

Thanks for your reply. I was able to establish the tunnel by
analyzing openswan failures on Sonicwall and comparing it against the
successfull Windows Sonicwall VPN client. The blasted Sonicwall
expects leftsubnet to be 0.0.0.0/0.0.0.0, so setting

leftsubnet=0.0.0.0/0.0.0.0

and turning off compression did the trick.

08:00:28 root at chayka [etc]> tunnel-up
002 "GroupVPN" #1: initiating Aggressive Mode #1, connection "GroupVPN"
112 "GroupVPN" #1: STATE_AGGR_I1: initiate
003 "GroupVPN" #1: ignoring unknown Vendor ID payload [5b362bc820f70001]
003 "GroupVPN" #1: ignoring unknown Vendor ID payload [404bf439522ca3f6]
003 "GroupVPN" #1: received Vendor ID payload [XAUTH]
002 "GroupVPN" #1: Aggressive mode peer ID is ID_FQDN: '@0017C51AEAE0'
002 "GroupVPN" #1: Aggressive mode peer ID is ID_FQDN: '@0017C51AEAE0'
002 "GroupVPN" #1: transition from state STATE_AGGR_I1 to state 
STATE_AGGR_I2
004 "GroupVPN" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established 
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha 
GroupVPN=modp1024}
041 "GroupVPN" #1: GroupVPN prompt for Username:
Name enter:   user1
040 "GroupVPN" #1: GroupVPN prompt for Password:
Enter secret:
002 "GroupVPN" #1: XAUTH: Answering XAUTH challenge with user='user1'
002 "GroupVPN" #1: transition from state STATE_XAUTH_I0 to state 
STATE_XAUTH_I1
004 "GroupVPN" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
002 "GroupVPN" #1: XAUTH: Successfully Authenticated
002 "GroupVPN" #1: transition from state STATE_XAUTH_I0 to state 
STATE_XAUTH_I1
004 "GroupVPN" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
002 "GroupVPN" #2: initiating Quick Mode 
PSK+ENCRYPT+TUNNEL+UP+AGGRESSIVE {using isakmp#1}
117 "GroupVPN" #2: STATE_QUICK_I1: initiate
002 "GroupVPN" #2: transition from state STATE_QUICK_I1 to state 
STATE_QUICK_I2
004 "GroupVPN" #2: STATE_QUICK_I2: sent QI2, IPsec SA established 
{ESP=>0x4246cd25 <0xa7fa3b8c xfrm=3DES_0-HMAC_SHA1 NATD=none DPD=none}

The tunnel is up, but the traffic doesn't seem to pass the traffic when
I try to ping host 192.168.26.198, on the rightsubnet:

08:00:52 root at chayka [mp]> tcpdump -i ipsec0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ipsec0, link-type EN10MB (Ethernet), capture size 96 bytes
08:00:59.587860 IP 192.168.1.103 > 192.168.26.198: ICMP echo request, id 
24856, seq 1, length 64
08:01:00.597484 IP 192.168.1.103 > 192.168.26.198: ICMP echo request, id 
24856, seq 2, length 64
08:01:01.597519 IP 192.168.1.103 > 192.168.26.198: ICMP echo request, id 
24856, seq 3, length 64

The routing after the ipsec tunnel comes up is as follows:

08:01:59 root at chayka [etc]>  netstat -rn
Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt 
Iface
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 
ath0
192.168.1.0     0.0.0.0         255.255.255.0   U         0 0          0 
ipsec0
192.168.25.0    0.0.0.0         255.255.255.0   U         0 0          0 
ipsec0
0.0.0.0         192.168.1.1     0.0.0.0         UG        0 0          0 
ath0

Configuration is:

version 2
config setup
         plutodebug="parsing"
         nat_traversal=yes
         nhelpers=0
         interfaces="ipsec0=eth0"
         plutoopts="--use-klips "
      virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/12
         nocrsend=yes

include /etc/ipsec.d/examples/no_oe.conf


conn group
   type=tunnel
   left=172.16.0.100
   leftsubnet=0.0.0.0/0.0.0.0
   leftid=@Laptop
   leftxauthclient=yes
   leftsendcert=no
   right=4.58.126.42
   rightid=@0017C51AEAE0
   rightxauthserver=yes
   rightsubnet=192.168.25.0/24
   rightnexthop=1.2.3.4
   aggrmode=yes
   auto=add
   auth=esp
   ike=3des-sha1-modp1024
   esp=3des-sha1
   pfs=no
   xauth=yes
   authby=secret

Any ideas why the traffic does not reach destination (tcpdump on the 
server does not show any incomming traffic)? Sonicwall is supposed to 
assign the DHCP address to the VPN clients to make them look like they 
are present on the rightsubnet.

Thanks for your help!

--p

Peter McGill wrote:
> NO_PROPOSAL_CHOSEN means you have a configuration
> mismatch between the two ipsec routers. So double
> check all your settings, in particular:
> 
> Make sure your left/rightsubnet values match on both ends.
> (They default to left/right, so your automatic leftsubnet
> is 172.16.0.100/32.)
> Make sure your phase 2 is using the same encryptions as
> phase 1 in your remote router. Ie) 3DES SHA1.
> Make sure your left/rightid values match on both ends.
> 
> 
> Peter McGill
>  
> 
>> -----Original Message-----
>> From: users-bounces at openswan.org 
>> [mailto:users-bounces at openswan.org] On Behalf Of Pawel Osiczko
>> Sent: March 11, 2008 12:46 AM
>> To: users at openswan.org
>> Subject: [Openswan Users] Not passing the "STATE_QUICK_I1: 
>> initiate" /NO_PROPOSAL_CHOSEN
>>