[Openswan Users] saref patch

Fri Nov 27 07:12:15 EST 2009

> I've applied it to FC7 kernel 2.6.23.17 and was finally
> able to get mast up, so it's going on the right way. 

Sorry for the inconvenience Paul, but after analyzing the results a
little further, I have a couple of doubts.

How does the mastX interface behaves? Do I have to set a interface for
it to bind to, as I did to ipsecX? I'm asking because I noticed that it
stays up even with openswan stopped, and it's IP is the one from my
internal interface. I tried setting 'interfaces="mast0=eth0"' but it
didn't make a difference.

Also, is openswan's native crypto required for saref? I was testing with
cryptoapi, and I don't get a kernel panic, but I have this error
instead, both with protostack=klips and protostack=mast:

Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: ignoring
Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000006]
Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: received
Vendor ID payload [RFC 3947] method set to=109
Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
already using method 109
Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: ignoring
Vendor ID payload [FRAGMENTATION]
Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: ignoring
Vendor ID payload [MS-Negotiation Discovery Capable]
Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: ignoring
Vendor ID payload [Vid-Initial-Contact]
Nov 27 10:03:11 inet pluto[4075]: packet from 192.168.1.5:500: ignoring
Vendor ID payload [IKE CGA version 1]
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: responding
to Main Mode from unknown peer 192.168.1.5
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
OAKLEY_GROUP 20 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
OAKLEY_GROUP 19 not supported.  Attribute OAKLEY_GROUP_DESCRIPTION
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: transition
from state STATE_MAIN_R0 to state STATE_MAIN_R1
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
STATE_MAIN_R1: sent MR1, expecting MI2
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
NAT-Traversal: Result using RFC 3947 (NAT-Traversal): peer is NATed
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: transition
from state STATE_MAIN_R1 to state STATE_MAIN_R2
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
STATE_MAIN_R2: sent MR2, expecting MI3
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: Main mode
peer ID is ID_DER_ASN1_DN: 'C=BR, ST=Sao Paulo, L=Piracicaba, O=Teste
MR, CN=mr.testmr.com.br'
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: I am
sending my cert
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: transition
from state STATE_MAIN_R2 to state STATE_MAIN_R3
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: new NAT
mapping for #1, was 192.168.1.5:500, now 192.168.1.5:4500
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
STATE_MAIN_R3: sent MR3, ISAKMP SA established {auth=OAKLEY_RSA_SIG
cipher=oakley_3des_cbc_192 prf=oakley_sha group=modp2048}
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1: the peer
proposed: 192.168.1.37/32:17/1701 -> 192.168.2.10/32:17/0
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #1:
NAT-Traversal: received 2 NAT-OA. using first, ignoring others
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #2: responding
to Quick Mode proposal {msgid:01000000}
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #2:     us:
192.168.1.37<192.168.1.37>[+S=C]:17/1701
Nov 27 10:03:11 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #2:   them:
192.168.1.5[C=BR, ST=Sao Paulo, L=Piracicaba, O=Teste MR,
CN=mr.testmr.com.br,+S=C]:17/1701===192.168.2.10/32
Nov 27 10:03:11 inet pluto[4075]: | NAT-OA: 32 tunnel: 0
Nov 27 10:03:11 inet pluto[4075]: ERROR: "MR-MR"[1] 192.168.1.5 #2:
pfkey write() of K_SADB_ADD message 5 for Add SA
esp.5a5b2b82 at 192.168.1.5 failed. Errno 71: Protocol error
Nov 27 10:03:11 inet pluto[4075]: |   02 03 00 03  18 00 00 00  05 00 00
00  eb 0f 00 00
Nov 27 10:03:11 inet pluto[4075]: |   03 00 01 00  5a 5b 2b 82  40 01 03
0c  00 00 00 00
Nov 27 10:03:11 inet pluto[4075]: |   00 00 00 00  00 00 00 00  03 00 05
00  00 00 00 00
Nov 27 10:03:11 inet pluto[4075]: |   02 00 06 a5  c0 a8 01 25  00 00 00
00  00 00 00 00
Nov 27 10:03:11 inet pluto[4075]: |   03 00 06 00  00 00 00 00  02 00 06
a5  c0 a8 01 05
Nov 27 10:03:11 inet pluto[4075]: |   00 00 00 00  00 00 00 00  04 00 08
00  a0 00 00 00
Nov 27 10:03:11 inet pluto[4075]: |   19 3d da b5  34 a3 03 fe  e2 21 94
b2  b5 03 d2 e5
Nov 27 10:03:11 inet pluto[4075]: |   37 40 ef bd  00 00 00 00  03 00 09
00  80 00 00 00
Nov 27 10:03:11 inet pluto[4075]: |   2e 75 a1 ed  f5 7c 99 75  36 f2 77
0f  71 21 66 a9
Nov 27 10:03:11 inet pluto[4075]: |   01 00 1b 00  02 00 00 00  01 00 1c
00  94 11 00 00
Nov 27 10:03:11 inet pluto[4075]: |   01 00 1d 00  94 11 00 00  03 00 1e
00  00 00 00 00
Nov 27 10:03:11 inet pluto[4075]: |   02 00 00 00  c0 a8 02 0a  00 00 00
00  00 00 00 00
Nov 27 10:03:11 inet pluto[4075]: | failed to install outgoing SA: 0
Nov 27 10:03:13 inet pluto[4075]: "MR-MR"[1] 192.168.1.5 #2: discarding
duplicate packet; already STATE_QUICK_R0

I'll try with the "regular" klips patch to see if I can reproduce this
behavior. 

Giovani

__________ Information from ESET NOD32 Antivirus, version of virus
signature database 4641 (20091127) __________

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com