[Openswan Users] Trouble completing phase 2 when using public IP as right subnet (expecting MR3)
Nic Pottier
nicpottier at gmail.com
Mon Mar 30 10:12:28 EDT 2015
As an aside, I'm both willing and able to pay for assistance on this
problem and actually looking for someone who can hop on Skype and help
me debug these type of issues now and then.
If you are interested, reply directly.
On Sun, Mar 29, 2015 at 4:07 PM, Nic Pottier <nicpottier at gmail.com> wrote:
> 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
More information about the Users
mailing list