[Openswan Users] aggressive mode to Cisco 3000

[Ken Bantoft]

On Tue, 2004-12-14 at 00:30 +0000, David Edmondson wrote:
> Seeing the recent addition of aggressive mode support (thanks!), I'm
> back trying to connect to my employer's Cisco 3000 VPN server.  My
> OpenSWAN is built from CVS today and is running on 2.6.9 (SMP, if that
> matters).
> 
> Under the impression that it's pretty standard stuff, I copied the
> example from the RELEASE-NOTES.txt and created /etc/ipsec.conf and
> /etc/ipsec.secrets (names and numbers changed):
> 


> Using "ipsec whack --name vpngw --initiate" to start the connection, I
> first had a problem with the failure:
> 
> 003 "vpngw" #1: protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 but ar
> e 17/0

Yes, we ran into this when the Cisco 3000 has NAT-Traversal support
explicitly turned on.  The Cisco proposal changes to something else
entirely.


> So I commented out the "return FALSE;" associated with that.  Now I get:
> 
> 002 "vpngw" #1: initiating Aggressive Mode #1, connection "vpngw"
> 112 "vpngw" #1: STATE_AGGR_I1: initiate
> 003 "vpngw" #1: received Vendor ID payload [Cisco-Unity]
> 003 "vpngw" #1: received Vendor ID payload [XAUTH]
> 003 "vpngw" #1: received Vendor ID payload [Dead Peer Detection]
> 003 "vpngw" #1: ignoring unknown Vendor ID payload [4048b7d56ebce88525e7de7f00d6
> c2d3c0000000]
> 003 "vpngw" #1: ignoring unknown Vendor ID payload [6acd600dad6e6ae5862dc6888192
> 459d]
> 003 "vpngw" #1: ignoring Vendor ID payload [Cisco VPN 3000 Series]
> 003 "vpngw" #1: protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 but ar
> e 17/0
> 002 "vpngw" #1: Aggressive mode peer ID is ID_IPV4_ADDR: '1.2.3.4'
> 003 "vpngw" #1: protocol/port in Phase 1 ID Payload must be 0/0 or 17/500 but ar
> e 17/0
> 002 "vpngw" #1: Aggressive mode peer ID is ID_IPV4_ADDR: '1.2.3.4'
> 002 "vpngw" #1: transition from state STATE_AGGR_I1 to state STATE_AGGR_I2
> 002 "vpngw" #1: sent AI2, ISAKMP SA established
> 004 "vpngw" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established
> 003 "vpngw" #1: XAUTH: Bad Message: Enter Username and Password.
> 041 "vpngw" #1: vpngw prompt for Username:
> Name enter:   dme
> 040 "vpngw" #1: vpngw prompt for Password:
> Enter secret: somerandomstuff
> 002 "vpngw" #1: XAUTH: Answering XAUTH challenge with user='dme'
> 002 "vpngw" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1
> 002 "vpngw" #1: XAUTH client - awaiting CFG_set
> 004 "vpngw" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
> 002 "vpngw" #1: XAUTH: Successfully Authenticated
> 002 "vpngw" #1: transition from state STATE_XAUTH_I0 to state STATE_XAUTH_I1
> 002 "vpngw" #1: XAUTH client - awaiting CFG_set
> 004 "vpngw" #1: STATE_XAUTH_I1: XAUTH client - awaiting CFG_set
> 002 "vpngw" #1: modecfg: Sending IP request (MODECFG_I1)
> 002 "vpngw" #1: received mode cfg reply
> 002 "vpngw" #1: setting client address to 1.2.3.99/32
> 002 "vpngw" #1: setting ip source address to 1.2.3.99/32
> 002 "vpngw" #1: transition from state STATE_MODE_CFG_I1 to state STATE_MAIN_I4
> 002 "vpngw" #1: ISAKMP SA established
> 004 "vpngw" #1: STATE_MAIN_I4: ISAKMP SA established
> 002 "vpngw" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+UP+MODECFGPULL+AGGRESSI
> VE {using isakmp#1}
> 117 "vpngw" #2: STATE_QUICK_I1: initiate
> 010 "vpngw" #2: STATE_QUICK_I1: retransmission; will wait 20s for response
> 010 "vpngw" #2: STATE_QUICK_I1: retransmission; will wait 40s for response
> 


I suspect the phase 2 proposals don't match, since the Cisco is
proposing something odd (17/0) and we aren't doing that.

Perhaps adding leftprotoport=17/0 and/or rightprotoport=17/0 might make
it happier.

Ken