[Openswan Users] Tunnel failing to come up
Managed Pvt nets
mpn at icabs.co.zw
Thu Jan 22 21:17:47 EST 2015
On 22/01/2015 11:32:24 PM, "Neal Murphy" <neal.p.murphy at alum.wpi.edu>
wrote:
>
>
>Below is a klips config I use; it's rather minimal and neither end is
>behind
>NAT. I don't know what translation is needed to make it work with
>netkey.
>
>version 2
>
>config setup
> protostack=klips
> interfaces=%defaultroute
> klipsdebug=none
> plutodebug=none
> plutowait=no
> uniqueids=yes
>
>conn clear
> auto=ignore
>
>conn clear-or-private
> auto=ignore
>
>conn private-or-clear
> auto=ignore
>
>conn private
> auto=ignore
>
>conn block
> auto=ignore
>
>conn packetdefault
> auto=ignore
>
>conn NAME
> ike=3des-md5
> esp=3des-md5
> authby=secret
> keyingtries=0
> left=a.b.c.d
> leftsubnet=g.h.i.j/24
> leftnexthop=%defaultroute
> right=w.x.y.z
> rightsubnet=m.n.o.p/24
> rightnexthop=%defaultroute
> compress=no
> auto=start
Definitely, heading in the right direction. I have tried to match your
configs with mine. I thought let me try and overwhelm you with a bit of
more information.
===
#tail -f /var/log/syslog
Jan 23 03:32:22 jupiter ipsec_setup: ...Openswan IPsec stopped
Jan 23 03:32:22 jupiter kernel: [153085.197222] NET: Registered protocol
family 15
Jan 23 03:32:22 jupiter ipsec_setup: Starting Openswan IPsec
U2.6.37/K3.2.0-4-amd64...
Jan 23 03:32:22 jupiter ipsec_setup: Using NETKEY(XFRM) stack
Jan 23 03:32:22 jupiter kernel: [153085.299584] Initializing XFRM
netlink socket
Jan 23 03:32:22 jupiter ipsec_setup: ...Openswan IPsec started
Jan 23 03:32:22 jupiter pluto: adjusting ipsec.d to /etc/ipsec.d
Jan 23 03:32:22 jupiter ipsec__plutorun: 002 added connection
description "tunnel1"
Jan 23 03:32:22 jupiter ipsec__plutorun: 104 "tunnel1" #1:
STATE_MAIN_I1: initiate
=====
#ipsec auto --status
[.../snip]
000 "tunnel1":
192.168.0.0/24===192.168.0.2<192.168.0.2>[a.b.c.d,+S=C]---192.168.0.1...192.168.0.1---w.x.y.z<w.x.y.z>[+S=C]===192.168.10.0/24;
prospective erouted; eroute owner: #0
000 "tunnel1": myip=unset; hisip=unset;
000 "tunnel1": ike_life: 3600s; ipsec_life: 28800s; rekey_margin:
540s; rekey_fuzz: 100%; keyingtries: 0
000 "tunnel1": policy:
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 24,24;
interface: eth1;
000 "tunnel1": newest ISAKMP SA: #1; newest IPsec SA: #0;
000 "tunnel1": IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)_000-MODP1536(5),
3DES_CBC(5)_000-SHA1(2)_000-MODP1024(2); flags=-strict
000 "tunnel1": IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1536(5),
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)
000 "tunnel1": IKE algorithm newest: 3DES_CBC_192-SHA1-MODP1024
000 "tunnel1": ESP algorithms wanted: 3DES(3)_000-SHA1(2)_000;
flags=-strict
000 "tunnel1": ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
000
000 #15: "tunnel1":4500 STATE_QUICK_I1 (sent QI1, expecting QR1);
EVENT_RETRANSMIT in 27s; nodpd; idle; import:admin initiate
000 #1: "tunnel1":4500 STATE_MAIN_I4 (ISAKMP SA established);
EVENT_SA_REPLACE in 1928s; newest ISAKMP; nodpd; idle; import:admin
initiate
000
=====
# ipsec auto --up tunnel1
117 "tunnel1" #22: STATE_QUICK_I1: initiate
010 "tunnel1" #22: STATE_QUICK_I1: retransmission; will wait 20s for
response
010 "tunnel1" #22: STATE_QUICK_I1: retransmission; will wait 40s for
response
031 "tunnel1" #22: max number of retransmissions (2) reached
STATE_QUICK_I1. No acceptable response to our first Quick Mode message:
perhaps peer likes no proposal
000 "tunnel1" #22: starting keying attempt 2 of an unlimited number, but
releasing whack
=====
#tail -f /var/log/pluto.log
added connection description "tunnel1"
listening for IKE messages
adding interface eth0/eth0 103.1.0.254:500
adding interface eth0/eth0 103.1.0.254:4500
adding interface eth1/eth1 192.168.0.2:500
adding interface eth1/eth1 192.168.0.2:4500
adding interface lo/lo 127.0.0.1:500
adding interface lo/lo 127.0.0.1:4500
adding interface lo/lo ::1:500
loading secrets from "/etc/ipsec.secrets"
"tunnel1" #1: initiating Main Mode
"tunnel1" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000006]
"tunnel1" #1: received Vendor ID payload [RFC 3947] method set to=109
"tunnel1" #1: received Vendor ID payload
[draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 109
"tunnel1" #1: ignoring Vendor ID payload [FRAGMENTATION]
"tunnel1" #1: ignoring Vendor ID payload [MS-Negotiation Discovery
Capable]
"tunnel1" #1: ignoring Vendor ID payload [IKE CGA version 1]
"tunnel1" #1: enabling possible NAT-traversal with method 4
"tunnel1" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
"tunnel1" #1: STATE_MAIN_I2: sent MI2, expecting MR2
"tunnel1" #1: NAT-Traversal: Result using RFC 3947 (NAT-Traversal): both
are NATed
"tunnel1" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
"tunnel1" #1: STATE_MAIN_I3: sent MI3, expecting MR3
"tunnel1" #1: Main mode peer ID is ID_IPV4_ADDR: 'w.x.y.z'
"tunnel1" #1: transition from state STATE_MAIN_I3 to state STATE_MAIN_I4
"tunnel1" #1: STATE_MAIN_I4: ISAKMP SA established
{auth=OAKLEY_PRESHARED_KEY cipher=oakley_3des_cbc_192 prf=oakley_sha
group=modp1024}
"tunnel1" #2: initiating Quick Mode
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK {using isakmp#1
msgid:4906d2be proposal=3DES(3)_192-SHA1(2)_160
pfsgroup=OAKLEY_GROUP_MODP1024}
"tunnel1" #1: ignoring informational payload, type
INVALID_ID_INFORMATION msgid=00000000
"tunnel1" #1: received and ignored informational message
"tunnel1" #1: ignoring informational payload, type
INVALID_ID_INFORMATION msgid=00000000
"tunnel1" #1: received and ignored informational message
===
There interesting part is the part in my /var/log/pluto.log where it
appears to be "ignoring Vendor ID payload". Could this mean that some
esp info from the remote side is being ignored?
MPN.
More information about the Users
mailing list