7

The issue

I´m having quite a hard time configuring OpenSWAN on my Linux server (Ubuntu 12.04) to connect to an ISA Server 2004 IPSec VPN. There is apparently something wrong in the configuration that impedes the tunnel from working. It looks like some of my packets are getting dropped somewhere? I'm not sure really.

The other party says there is nothing wrong in the logs on their side. I have no firewall on my side. Here's the offending part in /var/log/auth.log (longer version below).

Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Jan 29 17:28:12 P-INV-SD07 pluto[5821]: "myconn" #1: discarding duplicate packet; already STATE_MAIN_I3
Jan 29 17:28:34  pluto[5821]: last message repeated 3 times
Jan 29 17:28:42 P-INV-SD07 pluto[5821]: packet from <hispublicip>:500: Informational Exchange is for an unknown (expired?) SA with MSGID:0x8341092b
Jan 29 17:28:42 P-INV-SD07 pluto[5821]: "myconn" #1: discarding duplicate packet; already STATE_MAIN_I3

Next is detailed information about the setup in case anyone can help :) Thanks in advance!

The current configuration

I set up the connection with mostly default parameters on our side (I did try a bunch of other things, but nothing appears to work any better than this):

conn myconn
    authby=secret
    type=tunnel
    left=<hispublic>
    leftsubnet=<hislanip>/32
    right=<mypublic>
    rightsubnet=<mylanip>/32
    auto=start

Output from ipsec auto status:

000 "myconn": <mylanip>/32===<mypublicip><<mypublicip>>[+S=C]...<hispublicip>    <<hispublicip>>[+S=C]===<hislanip>/32; prospective erouted; eroute owner: #0
000 "myconn":     myip=unset; hisip=unset;
000 "myconn":   ike_life: 7200s; ipsec_life: 28800s; rekey_margin: 540s; rekey_fuzz:     100%; keyingtries: 0
000 "myconn":   policy: PSK+ENCRYPT+TUNNEL+PFS+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD;   prio:   32,32; interface: eth0;
000 "myconn":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000
000 #2: "myconn":500 STATE_MAIN_I3 (sent MI3, expecting MR3); EVENT_RETRANSMIT in 18s;     nodpd; idle; import:admin initiate
000 #2: pending Phase 2 for "myconn" replacing #0

The excerpt from /var/log/auth.log:

Jan 29 17:28:11 P-INV-SD07 pluto[5821]: loading secrets from "/etc/ipsec.secrets"
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: initiating Main Mode
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: ignoring Vendor ID payload [MS NT5 ISAKMPOAKLEY 00000004]
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: ignoring Vendor ID payload [FRAGMENTATION]
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] method set to=106
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: enabling possible NAT-traversal     with method draft-ietf-ipsec-nat-t-ike-05
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: transition from state STATE_MAIN_I1 to state STATE_MAIN_I2
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: STATE_MAIN_I2: sent MI2, expecting    MR2
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: no NAT detected
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: transition from state STATE_MAIN_I2 to state STATE_MAIN_I3
Jan 29 17:28:11 P-INV-SD07 pluto[5821]: "myconn" #1: STATE_MAIN_I3: sent MI3, expecting MR3
Jan 29 17:28:12 P-INV-SD07 pluto[5821]: "myconn" #1: discarding duplicate packet; already STATE_MAIN_I3
Jan 29 17:28:34  pluto[5821]: last message repeated 3 times
Jan 29 17:28:42 P-INV-SD07 pluto[5821]: packet from <hispublicip>:500: Informational Exchange is for an unknown (expired?) SA with MSGID:0x8341092b
Jan 29 17:28:42 P-INV-SD07 pluto[5821]: "myconn" #1: discarding duplicate packet; already STATE_MAIN_I3

Here are the configuration options used on the ISA Server Side:

  • Phase 1
    • Encryption: 3DES
    • Integrity: SHA1
    • DH Group: Group 2
  • Phase 2
    • Encryption: 3DES
    • Integrity: SHA1
    • Generate a new key every 86400 seconds
    • Use PFS: yes (DH Group 2)

Update

I managed to get a packet sniffer running on the OpenSWAN side, and the Oakley log enabled on the ISA side. The sniff is pretty much what you'd expect: the 3rd packet sent from the OpenSWAN side gets rejected by the ISA server, who keeps sending its 2nd packet because he thinks it wasn't ACK'd.

The error on the Oakley (ISA) log says:

Receive: (get) SA = 0x00108cf0 from 50.57.73.135.500
2-07: 14:44:25:250:44b24 ISAKMP Header: (V1.0), len = 68
2-07: 14:44:25:250:44b24   I-COOKIE 8802248fab719171
2-07: 14:44:25:250:44b24   R-COOKIE 296787dc0ec4227a
2-07: 14:44:25:250:44b24   exchange: Oakley Main Mode
2-07: 14:44:25:250:44b24   flags: 1 ( encrypted )
2-07: 14:44:25:250:44b24   next payload: ID
2-07: 14:44:25:250:44b24   message ID: 00000000
2-07: 14:44:25:250:44b24 invalid payload received
2-07: 14:44:25:250:44b24 Preshared key ID.  Peer IP Address: <mypublicip>
2-07: 14:44:25:250:44b24 Source IP Address <hispublicip>  Source IP Address Mask 255.255.255.255  Destination IP Address <mypublicip>  Destination IP Address Mask 255.255.255.255  Protocol 0  Source Port 0  Destination Port 0  IKE Local Addr <hispublicip>  IKE Peer Addr <mypublicip>  IKE Source Port 500  IKE Destination Port 500  Peer Private Addr
2-07: 14:44:25:250:44b24 GetPacket failed 3613

So basically invalid payload received and then GetPacket failed 3613. This last error code doesn't yield a lot on info upon Googling, including people saying that they get this all the time and everything works nonetheless.

I gave up, we're setting up a local server, but I'm updating this for future reference in case anyone has a clue for the Internet's sake.

1
  • From what I´m hearing, the problem is on the other side (or a firewall issue). The fact that the other end is sending duplicate packets my way means some of my messages aren´t getting through.
    – GomoX
    Jan 30, 2013 at 13:38

1 Answer 1

3

I've came across this situation in recent days.

It was due to two issues.

  1. Firewall
  2. Kernal IP forwarding disabled
  3. Preshared-key mismatch

For firewall, it turns out port 500 and 4500 were blocked. By running ipsec verify, you can see whether 500 or 4500 blocked.

In /etc/sysctl.conf,

change net.ipv4.ip_forward to 1

append

net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.lo.accept_redirects = 0
net.ipv4.conf.lo.send_redirects = 0
net.ipv4.conf.em1.accept_redirects = 0
net.ipv4.conf.em1.send_redirects = 0

The em1 is the network interface, yours maybe eth0 or eth1

Finally, in my case, the preshared key in /etc/ipsec.d/ipsec.secrets were mistakenly enclosed with double quote ", which result in preshared key mismatch.

Hope it helps somebody.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .