[Openswan Users] Trouble completing phase 2 when using public IP as right subnet (expecting MR3)

[Nic Pottier]

Hi Everyone,

First a caveat, I'm by no means a networking expert, but I've set up
about a dozen tunnels using OpenSwan with various providers in the
past few months so have cut my teeth and learned a few lessons the
hard way. Those lessons have definitely been of the variety that I've
made mistakes that needed correcting.

The last two tunnels I've had to set up are both suffering from the
same problem though and I suspect this is a problem in configuration
that I'm just not familiar with. These are both interesting in that
the other side (right) has chosen to set up their private IPs to be
masks of their machine's public IPs. That is, they aren't in a private
address space like 172.16.* but instead in the standard public IP
space and I presume the actual public IPs to the machines. Normally I
wouldn't think twice of this, but these two tunnels are having trouble
coming up despite my best efforts and it is their one distinguishing
characteristic.

I'm including the last of these as I have the configuration on both
sides of the tunnel available to me. If anybody can lend a helping
hand that would be much appreciated, as I said I'm sure I'm doing
something wrong, just not sure what..

The symptom is that the tunnel doesn't seem to complete Phase 2, and
the log seems to show a cycle of:
   pending Quick Mode with 213.177.161.90 "vpc-to-cf-bar" took too
long -- replacing phase 1
with waiting for:
  STATE_MAIN_I3: sent MI3, expecting MR3

Full log below. Any advice on what might be the problem and where to
look? Just looking for a path towards finding what the problem might
be and I've exhausted my usual routes.

First, the configuration on their side, as I understand it is a Juniper router:

Phase1:
========
proposal Phoo_phase1-proposal {
            authentication-method pre-shared-keys;
            dh-group group2;
            authentication-algorithm sha1;
            encryption-algorithm 3des-cbc;
            lifetime-seconds 28800;

policy RapidPro_phase1_policy {
            mode main;
            proposals Phoo_phase1-proposal;
            pre-shared-key ascii-text "ALLYOURBASE";

gateway Phoo_phase1_gateway {
            ike-policy Phoo_phase1_policy;
            address 54.208.213.64;
            external-interface reth4.100;
        }

Phase2:
========
proposal Phoo_phase2_proposal {
            protocol esp;
            authentication-algorithm hmac-sha1-96;
            encryption-algorithm 3des-cbc;
            lifetime-seconds 3600;
vpn to_Phoo {
            bind-interface st0.14;
            ike {
                gateway Phoo_phase1_gateway;
                proxy-identity {
                    local 213.177.160.112/30;
                    remote 172.16.10.10/32;
                    service any;
                }
                ipsec-policy Phoo_phase2_policy;
            }
            establish-tunnels immediately;
}

On my side, I have the following (I also have the PSK set in
ipsec.secrets appropriately for 213.177.161.90)

version 2.0 #
config setup
    protostack=netkey
    nat_traversal=yes
    oe=off

conn vpc-to-cf-bar
     type=tunnel
     authby=secret
     left=%defaultroute
     leftid=54.208.213.64
     leftnexthop=%defaultroute
     leftsubnet=172.16.10.10/32
     right=213.177.161.90
     rightsubnet=213.177.160.112/30
     auto=start
     ikelifetime=86400s
     keylife=8h
     pfs=no

     ike=3des-sha1;modp1024!
     phase2alg=3des-sha1;modp1024

     dpddelay=10
     dpdtimeout=30
     dpdaction=restart_by_peer

Here is the output to ipsec barf for messages related to this connection:

000 "vpc-to-cf-bar":
172.16.10.10/32===172.16.10.10[54.208.213.64,+S=C]---172.16.10.1...213.177.161.90<213.177.161.90>[+S=C]===213.177.160.112/30;
prospective erouted; eroute owner: #0
000 "vpc-to-cf-bar":     myip=unset; hisip=unset;
000 "vpc-to-cf-bar":   ike_life: 86400s; ipsec_life: 28800s;
rekey_margin: 540s; rekey_fuzz: 100%; keyingtries: 0
000 "vpc-to-cf-bar":   policy:
PSK+ENCRYPT+TUNNEL+UP+IKEv2ALLOW+SAREFTRACK+lKOD+rKOD; prio: 32,30;
interface: eth0;
000 "vpc-to-cf-bar":   dpd: action:restart_by_peer; delay:10; timeout:30;
000 "vpc-to-cf-bar":   newest ISAKMP SA: #0; newest IPsec SA: #0;
000 "vpc-to-cf-bar":   IKE algorithms wanted:
3DES_CBC(5)_000-SHA1(2)_000-MODP1024(2); flags=strict
000 "vpc-to-cf-bar":   IKE algorithms found:
3DES_CBC(5)_192-SHA1(2)_160-MODP1024(2)
000 "vpc-to-cf-bar":   ESP algorithms wanted: 3DES(3)_000-SHA1(2)_000;
pfsgroup=MODP1024(2); flags=-strict
000 "vpc-to-cf-bar":   ESP algorithms loaded: 3DES(3)_192-SHA1(2)_160
000 #25: "vpc-to-cf-bar":4500 STATE_MAIN_I3 (sent MI3, expecting MR3);
EVENT_RETRANSMIT in 0s; lastdpd=-1s(seq in:0 out:0); idle;
import:admin initiate
000 #25: pending Phase 2 for "vpc-to-cf-bar" replacing #0

Mar 29 19:56:56 vpgateway ipsec__plutorun: 002 added connection
description "vpc-to-cf-bar"
Mar 29 19:56:57 vpgateway ipsec__plutorun: 104 "vpc-to-cf-bar" #6:
STATE_MAIN_I1: initiate
Mar 29 19:56:56 vpgateway pluto[699]: added connection description
"vpc-to-cf-bar"
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: initiating Main Mode
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: received
Vendor ID payload [Dead Peer Detection]
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: ignoring
unknown Vendor ID payload
[699369228741c6d4ca094c93e242c9de19e7b7c60000000500000500]
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: ignoring
Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: ignoring
Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] method set to=107
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
already using method 107
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: enabling
possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-05
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6: transition
from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mar 29 19:56:57 vpgateway pluto[699]: "vpc-to-cf-bar" #6:
STATE_MAIN_I2: sent MI2, expecting MR2
Mar 29 19:58:08 vpgateway pluto[699]: "vpc-to-cf-bar" #6: max number
of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication
failure: no acceptable response to our first encrypted message
Mar 29 19:58:08 vpgateway pluto[699]: "vpc-to-cf-bar" #6: starting
keying attempt 2 of an unlimited number
Mar 29 19:58:08 vpgateway pluto[699]: "vpc-to-cf-bar" #24: initiating
Main Mode to replace #6
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: received
Vendor ID payload [Dead Peer Detection]
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: ignoring
unknown Vendor ID payload
[699369228741c6d4ca094c93e242c9de19e7b7c60000000500000500]
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: ignoring
Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: ignoring
Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] method set to=107
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
already using method 107
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: enabling
possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-05
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: transition
from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24:
STATE_MAIN_I2: sent MI2, expecting MR2
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am
NATed
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24: transition
from state STATE_MAIN_I2 to state STATE_MAIN_I3
Mar 29 19:58:09 vpgateway pluto[699]: "vpc-to-cf-bar" #24:
STATE_MAIN_I3: sent MI3, expecting MR3
Mar 29 19:58:56 vpgateway pluto[699]: pending Quick Mode with
213.177.161.90 "vpc-to-cf-bar" took too long -- replacing phase 1
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: initiating
Main Mode to replace #24
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: received
Vendor ID payload [Dead Peer Detection]
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: ignoring
unknown Vendor ID payload
[699369228741c6d4ca094c93e242c9de19e7b7c60000000500000500]
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: ignoring
Vendor ID payload [draft-stenberg-ipsec-nat-traversal-01]
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: ignoring
Vendor ID payload [draft-stenberg-ipsec-nat-traversal-02]
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-00]
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] method set to=107
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but
already using method 107
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: received
Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] method set to=108
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: enabling
possible NAT-traversal with method draft-ietf-ipsec-nat-t-ike-05
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25: transition
from state STATE_MAIN_I1 to state STATE_MAIN_I2
Mar 29 19:58:56 vpgateway pluto[699]: "vpc-to-cf-bar" #25:
STATE_MAIN_I2: sent MI2, expecting MR2
Mar 29 19:58:57 vpgateway pluto[699]: "vpc-to-cf-bar" #25:
NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike-02/03: i am
NATed
Mar 29 19:58:57 vpgateway pluto[699]: "vpc-to-cf-bar" #25: transition
from state STATE_MAIN_I2 to state STATE_MAIN_I3
Mar 29 19:58:57 vpgateway pluto[699]: "vpc-to-cf-bar" #25:
STATE_MAIN_I3: sent MI3, expecting MR3
Mar 29 20:00:07 vpgateway pluto[699]: "vpc-to-cf-bar" #25: max number
of retransmissions (2) reached STATE_MAIN_I3.  Possible authentication
failure: no acceptable response to our first encrypted message
Mar 29 20:00:07 vpgateway pluto[699]: "vpc-to-cf-bar" #25: starting
keying attempt 2 of an unlimited number
Mar 29 20:00:07 vpgateway pluto[699]: "vpc-to-cf-bar" #26: initiating
Main Mode to replace #25