Re: [Swan] Stronswan / Libreswan - Tunnel disconnects and becomes prospective erouted
Hi List,
To further the issue below I've adjusted the key lengths as suggested and got
the third party to do the same. We had a repeat of the connection issue that I
describe in the email below.
The connection from our view appears to be operational. An ipsec status
provided me with:
http://pastebin.com/YzZHJ82r
This suggests that our VPN tunnels are up however the strongswan 5.1.3 instance
we connect to only has one tunnel operational and it suggests the others are
down.
The open of the stronswan restarted his instance to find that the same tunnel
came up but from our point of view it looks as if the that instance only sent
one proposal. Please see Oct 10 14:48:49 in the log below.
http://pastebin.com/pFQ42tG9
I'm at a loss of what to try we know our instance is stable with another VPN
using similar configuration it only appears to be this strongswan system which
is problematic.
If anyone has any suggestions I would be grateful!
Thanks
Joe
-Original Message-
From: Paul Wouters [mailto:p...@nohats.ca]
Sent: 20 September 2016 17:18
To: Madden, Joe
Cc: swan@lists.libreswan.org
Subject: Re: [Swan] Stronswan / Libreswan - Tunnel disconnects and becomes
prospective erouted
On Tue, 20 Sep 2016, Madden, Joe wrote:
> Just trying to resolve an issue we have with VPN’s disconnecting from a
> Stronswan client.
>
> When I restart my end of the VPN the VPNs establish and operate fine.
> After a random amount of time with no apparent user action the some of the
> VPN tunnels will become “prospective erouted”
you didnt provide any logs, so we have no idea of what is actually happening.
Are they hanging up? Are you hanging up? Are they trying to rekey to you? The
only thing we know is that this is ikev1, so it does not relate to rekeying
without authentication.
> keylife= 60m
> ikelifetime= 480m
You could try and change these timings. An 1h IPsec SA lifetime is pretty short
- usually these are kept at 8h or 24h. It does not matter too much other than
that you can tweak these to determine who gets to initiate the rekeying
(whoever has the shortest keylife)
But check your logs to see what is going on when the failure is happening.
Paul
From: Swan [mailto:swan-boun...@lists.libreswan.org] On Behalf Of Madden, Joe
Sent: 20 September 2016 16:54
To: swan@lists.libreswan.org
Subject: [Swan] Stronswan / Libreswan - Tunnel disconnects and becomes
prospective erouted
Hi List,
Just trying to resolve an issue we have with VPN’s disconnecting from a
Stronswan client.
When I restart my end of the VPN the VPNs establish and operate fine. After a
random amount of time with no apparent user action the some of the VPN tunnels
will become “prospective erouted”
Our configuration is:
# basic configuration
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
#plutodebug="all"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/16
#plutodebug=control
oe=off
# Enable this if you see "failed to find any available worker"
# nhelpers=0
#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and
uncomment this.
include /etc/ipsec.d/*.conf
conn ssl-iptrafficsig-1
authby= secret
auto= start
type= tunnel
nat_traversal= yes
forceencaps=no
rekeymargin=3m
keyingtries=%forever
keylife=60m
ikelifetime=480m
ikev2= no
#RTT
left= 10.59.31.49
leftsubnets=
{10.2.170.0/26,10.1.178.0/26,10.1.160.64/27,10.1.162.64/27,10.1.176.0/25,10.1.170.0/25,10.2.166.0/26,10.2.74.64/29,10.2.166.0/26,10.2.130.64/28,10.2.168.10/32,10.2.168.11/32,10.1.172.10/32,10.1.172.11/32}
leftid= 193.195.162.135
leftnexthop=10.59.31.54
leftsourceip= 10.59.31.49
#SAA
right= 52.48.93.253
rightid=52.48.93.253
rightsubnet=10.199.0.0/28
ike=aes256-sha2_256;modp2048
phase2= esp
phase2alg= aes256-sha2_256;modp2048
pfs=yes
sha2_truncbug= no
#Dead Peer Detection
dpdaction= restart
Ipsec status shows:
000 "ssl-iptrafficsig-1/10x0":
10.2.130.64/28===10.59.31.49<10.59.31.49>[LOCAL_END_HOST]---10.59.31.54...REMOTE_END_HOST===10.199.0.0/28;
erouted; eroute owner: #5
000 "ssl-iptrafficsig-1/10x0": oriented; my_ip=10.59.31.49; their_ip=unset
000 "ssl-iptrafficsig-1/10x0": xauth info: us:none, them:none,
my_xauthuser=[any]; their_xauthuser=[any]
000 "ssl-iptra
Re: [Swan] Stronswan / Libreswan - Tunnel disconnects and becomes prospective erouted
Hi Paul, Thanks for the reply. I'll change the key values to the longer ones and monitor to see what happened. I also noticed that I had duplicate subnets in there 10.2.166.0/26. I'll let you know how I get on. Thanks Joe -Original Message- From: Paul Wouters [mailto:p...@nohats.ca] Sent: 20 September 2016 17:18 To: Madden, Joe Cc: swan@lists.libreswan.org Subject: Re: [Swan] Stronswan / Libreswan - Tunnel disconnects and becomes prospective erouted On Tue, 20 Sep 2016, Madden, Joe wrote: > Just trying to resolve an issue we have with VPN’s disconnecting from a > Stronswan client. > > When I restart my end of the VPN the VPNs establish and operate fine. > After a random amount of time with no apparent user action the some of the > VPN tunnels will become “prospective erouted” you didnt provide any logs, so we have no idea of what is actually happening. Are they hanging up? Are you hanging up? Are they trying to rekey to you? The only thing we know is that this is ikev1, so it does not relate to rekeying without authentication. > keylife= 60m > ikelifetime= 480m You could try and change these timings. An 1h IPsec SA lifetime is pretty short - usually these are kept at 8h or 24h. It does not matter too much other than that you can tweak these to determine who gets to initiate the rekeying (whoever has the shortest keylife) But check your logs to see what is going on when the failure is happening. Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
Re: [Swan] Stronswan / Libreswan - Tunnel disconnects and becomes prospective erouted
On Tue, 20 Sep 2016, Madden, Joe wrote: Just trying to resolve an issue we have with VPN’s disconnecting from a Stronswan client. When I restart my end of the VPN the VPNs establish and operate fine. After a random amount of time with no apparent user action the some of the VPN tunnels will become “prospective erouted” you didnt provide any logs, so we have no idea of what is actually happening. Are they hanging up? Are you hanging up? Are they trying to rekey to you? The only thing we know is that this is ikev1, so it does not relate to rekeying without authentication. keylife= 60m ikelifetime= 480m You could try and change these timings. An 1h IPsec SA lifetime is pretty short - usually these are kept at 8h or 24h. It does not matter too much other than that you can tweak these to determine who gets to initiate the rekeying (whoever has the shortest keylife) But check your logs to see what is going on when the failure is happening. Paul ___ Swan mailing list Swan@lists.libreswan.org https://lists.libreswan.org/mailman/listinfo/swan
[Swan] Stronswan / Libreswan - Tunnel disconnects and becomes prospective erouted
Hi List,
Just trying to resolve an issue we have with VPN's disconnecting from a
Stronswan client.
When I restart my end of the VPN the VPNs establish and operate fine. After a
random amount of time with no apparent user action the some of the VPN tunnels
will become "prospective erouted"
Our configuration is:
# basic configuration
config setup
# Debug-logging controls: "none" for (almost) none, "all" for lots.
# klipsdebug=none
#plutodebug="all"
# For Red Hat Enterprise Linux and Fedora, leave protostack=netkey
protostack=netkey
nat_traversal=yes
virtual_private=%v4:10.0.0.0/8,%v4:192.168.0.0/16,%v4:172.16.0.0/16
#plutodebug=control
oe=off
# Enable this if you see "failed to find any available worker"
# nhelpers=0
#You may put your configuration (.conf) file in the "/etc/ipsec.d/" and
uncomment this.
include /etc/ipsec.d/*.conf
conn ssl-iptrafficsig-1
authby= secret
auto= start
type= tunnel
nat_traversal= yes
forceencaps=no
rekeymargin=3m
keyingtries=%forever
keylife=60m
ikelifetime=480m
ikev2= no
#RTT
left= 10.59.31.49
leftsubnets=
{10.2.170.0/26,10.1.178.0/26,10.1.160.64/27,10.1.162.64/27,10.1.176.0/25,10.1.170.0/25,10.2.166.0/26,10.2.74.64/29,10.2.166.0/26,10.2.130.64/28,10.2.168.10/32,10.2.168.11/32,10.1.172.10/32,10.1.172.11/32}
leftid= 193.195.162.135
leftnexthop=10.59.31.54
leftsourceip= 10.59.31.49
#SAA
right= 52.48.93.253
rightid=52.48.93.253
rightsubnet=10.199.0.0/28
ike=aes256-sha2_256;modp2048
phase2= esp
phase2alg= aes256-sha2_256;modp2048
pfs=yes
sha2_truncbug= no
#Dead Peer Detection
dpdaction= restart
Ipsec status shows:
000 "ssl-iptrafficsig-1/10x0":
10.2.130.64/28===10.59.31.49<10.59.31.49>[LOCAL_END_HOST]---10.59.31.54...REMOTE_END_HOST===10.199.0.0/28;
erouted; eroute owner: #5
000 "ssl-iptrafficsig-1/10x0": oriented; my_ip=10.59.31.49; their_ip=unset
000 "ssl-iptrafficsig-1/10x0": xauth info: us:none, them:none,
my_xauthuser=[any]; their_xauthuser=[any]
000 "ssl-iptrafficsig-1/10x0": modecfg info: us:none, them:none, modecfg
policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset;
000 "ssl-iptrafficsig-1/10x0": labeled_ipsec:no;
000 "ssl-iptrafficsig-1/10x0": policy_label:unset;
000 "ssl-iptrafficsig-1/10x0": ike_life: 28800s; ipsec_life: 3600s;
rekey_margin: 180s; rekey_fuzz: 100%; keyingtries: 0;
000 "ssl-iptrafficsig-1/10x0": retransmit-interval: 500ms;
retransmit-timeout: 60s;
000 "ssl-iptrafficsig-1/10x0": sha2_truncbug:no; initial_contact:no;
cisco_unity:no; send_vendorid:no;
000 "ssl-iptrafficsig-1/10x0": policy:
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
000 "ssl-iptrafficsig-1/10x0": conn_prio: 28,28; interface: eth1; metric: 0;
mtu: unset; sa_prio:auto; nflog-group: unset;
000 "ssl-iptrafficsig-1/10x0": newest ISAKMP SA: #0; newest IPsec SA: #5;
000 "ssl-iptrafficsig-1/10x0": aliases: ssl-iptrafficsig-1
000 "ssl-iptrafficsig-1/10x0": IKE algorithms wanted:
AES_CBC(7)_256-SHA2_256(4)_000-MODP2048(14)
000 "ssl-iptrafficsig-1/10x0": IKE algorithms found:
AES_CBC(7)_256-SHA2_256(4)_256-MODP2048(14)
000 "ssl-iptrafficsig-1/10x0": ESP algorithms wanted:
AES(12)_256-SHA2_256(5)_000; pfsgroup=MODP2048(14)
000 "ssl-iptrafficsig-1/10x0": ESP algorithms loaded:
AES(12)_256-SHA2_256(5)_000
000 "ssl-iptrafficsig-1/10x0": ESP algorithm newest: AES_256-HMAC_SHA2_256;
pfsgroup=MODP2048
000 "ssl-iptrafficsig-1/11x0":
10.2.168.10/32===10.59.31.49<10.59.31.49>[LOCAL_END_HOST]---10.59.31.54...REMOTE_END_HOST===10.199.0.0/28;
erouted; eroute owner: #6
000 "ssl-iptrafficsig-1/11x0": oriented; my_ip=10.59.31.49; their_ip=unset
000 "ssl-iptrafficsig-1/11x0": xauth info: us:none, them:none,
my_xauthuser=[any]; their_xauthuser=[any]
000 "ssl-iptrafficsig-1/11x0": modecfg info: us:none, them:none, modecfg
policy:push, dns1:unset, dns2:unset, domain:unset, banner:unset;
000 "ssl-iptrafficsig-1/11x0": labeled_ipsec:no;
000 "ssl-iptrafficsig-1/11x0": policy_label:unset;
000 "ssl-iptrafficsig-1/11x0": ike_life: 28800s; ipsec_life: 3600s;
rekey_margin: 180s; rekey_fuzz: 100%; keyingtries: 0;
000 "ssl-iptrafficsig-1/11x0": retransmit-interval: 500ms;
retransmit-timeout: 60s;
000 "ssl-iptrafficsig-1/11x0": sha2_truncbug:no; initial_contact:no;
cisco_unity:no; send_vendorid:no;
000 "ssl-iptrafficsig-1/11x0": policy:
PSK+ENCRYPT+TUNNEL+PFS+UP+IKEV1_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW;
000 "ssl-iptrafficsig-1/11x0": conn_prio: 32,28; interface: eth1; metric: 0;
mtu: unset; sa_prio:auto; nflog-group: unset;
000 "ssl-iptrafficsig-1/11x0
