From jessy3g at gmail.com  Fri Jan 20 12:14:43 2023
From: jessy3g at gmail.com (Jesse)
Date: Fri, 20 Jan 2023 13:14:43 +0300
Subject: [Swan] IPsec Failover Multiple Peer Connections to 1 Private IP
Message-ID: <CAD-i5HNOEqOZ94=rsz9jy=gQq-ESPi8EruD+ZFy=Wy=S4C1eSw@mail.gmail.com>

Hello,

I have an issue I am using
Linux Libreswan 3.32 (netkey) on 5.15.0-1027-oracle
on my Oracle Ubuntu 22.04 instance.

I have a partner Connection from my instance and the partner has a primary
IP and a Failover IP
eg.
Connection to partner from my end via 197.XXX.XXX.X to NAT IP 10.10.13.5
Failover is
Connection to partner from my end via 41.XXX.XXX.X to NAT IP 10.10.13.5
When i try adding the same NAT IP on differente configurations i get the
error
*cannot install eroute -- it is in use for*

How can i set the PEER NAT IP for both Connections and enable redundancy.

Regards
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20230120/e383b09e/attachment.htm>

From paul at nohats.ca  Mon Jan 23 19:14:51 2023
From: paul at nohats.ca (Paul Wouters)
Date: Mon, 23 Jan 2023 12:14:51 -0500 (EST)
Subject: [Swan] IPsec Failover Multiple Peer Connections to 1 Private IP
In-Reply-To: <CAD-i5HNOEqOZ94=rsz9jy=gQq-ESPi8EruD+ZFy=Wy=S4C1eSw@mail.gmail.com>
References: <CAD-i5HNOEqOZ94=rsz9jy=gQq-ESPi8EruD+ZFy=Wy=S4C1eSw@mail.gmail.com>
Message-ID: <6076dab8-265a-ef7d-7f22-77af98bc417f@nohats.ca>

On Fri, 20 Jan 2023, Jesse wrote:

> I have an issue I am using?
> Linux Libreswan 3.32 (netkey) on 5.15.0-1027-oracle
> on my Oracle Ubuntu 22.04 instance.?
> 
> I have a partner Connection from my instance and the partner has a primary IP and a Failover IP?
> eg.?
> Connection to partner from my end via 197.XXX.XXX.X to NAT IP 10.10.13.5?
> Failover is
> Connection to partner from my end via 41.XXX.XXX.X to NAT IP 10.10.13.5
> When i try adding the same NAT IP on differente configurations i get the error
> cannot install eroute -- it is in use for
> 
> How can i set the PEER NAT IP for both Connections and enable redundancy.

libreswan 3.x and 4.x did not take into account to install identical
policies multiple times. libreswan 5.0 (not yet released) will allow this,
provided the marks or priority are different.

For now, your easiest bet is to write your own failover handler that
--downs and --ups the proper connection.

Paul

From jessy3g at gmail.com  Mon Jan 23 19:31:40 2023
From: jessy3g at gmail.com (Jesse)
Date: Mon, 23 Jan 2023 20:31:40 +0300
Subject: [Swan] IPsec Failover Multiple Peer Connections to 1 Private IP
In-Reply-To: <6076dab8-265a-ef7d-7f22-77af98bc417f@nohats.ca>
References: <CAD-i5HNOEqOZ94=rsz9jy=gQq-ESPi8EruD+ZFy=Wy=S4C1eSw@mail.gmail.com>
 <6076dab8-265a-ef7d-7f22-77af98bc417f@nohats.ca>
Message-ID: <CAD-i5HOGs1dmXG4Y3oAc--qkHbhcXDvCcB9c8TXczbaugBVkkg@mail.gmail.com>

Hello Paul,

Thank Your for this confirmation.

I will get down to that. Can't wait for Libreswan Version 5.

Regards
Sent from my One Plus CE 5G

On Mon, Jan 23, 2023, 8:14 PM Paul Wouters <paul at nohats.ca> wrote:

> On Fri, 20 Jan 2023, Jesse wrote:
>
> > I have an issue I am using
> > Linux Libreswan 3.32 (netkey) on 5.15.0-1027-oracle
> > on my Oracle Ubuntu 22.04 instance.
> >
> > I have a partner Connection from my instance and the partner has a
> primary IP and a Failover IP
> > eg.
> > Connection to partner from my end via 197.XXX.XXX.X to NAT IP 10.10.13.5
> > Failover is
> > Connection to partner from my end via 41.XXX.XXX.X to NAT IP 10.10.13.5
> > When i try adding the same NAT IP on differente configurations i get the
> error
> > cannot install eroute -- it is in use for
> >
> > How can i set the PEER NAT IP for both Connections and enable redundancy.
>
> libreswan 3.x and 4.x did not take into account to install identical
> policies multiple times. libreswan 5.0 (not yet released) will allow this,
> provided the marks or priority are different.
>
> For now, your easiest bet is to write your own failover handler that
> --downs and --ups the proper connection.
>
> Paul
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20230123/fad2125a/attachment.htm>

From ud at blueaquan.com  Sun Jan 29 17:33:51 2023
From: ud at blueaquan.com (ud at blueaquan.com)
Date: Sun, 29 Jan 2023 21:03:51 +0530
Subject: [Swan] [SPAM: 4.729] Tunnel gets established,
 but machines can reach each other only for less than a minute
Message-ID: <e98b098de24169ed6e8eee9cbb2f1d37@blueaquan.com>


Dear friends/ Team
I have two sites which I am trying to connect using a site-to-site VPN.  
Initially I had a lot of challenges because at the HO, the Linux machine 
had a Public IP directly configured, while at the Site Office the Linux 
machine was behind an ISP router. Anyhow the tunnel gets established 
now, but machines on both sides cannot reach each other.

However, when I reboot the Site Office machine and it comes up, tunnel 
also gets established and both sides can reach each other for roughly 
less than a minute and then it stops.

FYI, the machine at HO is running Libreswan 4.3 and the one at Site 
Office is running Libreswan 4.4

What is changing when the machine comes up after a reboot...?

The HO Configuration

conn PLUTOSUBNET
     also=EUROPA-PLUTO
     leftsubnet=10.10.128.0/24
     leftsourceip=10.10.128.100
     rightsubnet=192.168.1.0/24
     rightsourceip=192.168.1.1
     auto=start
conn EUROPA-PLUTO
     type=tunnel
     left=W.X.Y.Z
     right=A.B.C.D
     authby=secret
     ikev2=insist
     pfs=no
     ike=aes256-sha2_512+sha2_256-dh21
     esp=aes256-sha2_512+sha1+sha2_256;dh21
     dpddelay=5
     dpdtimeout=120
     dpdaction=restart
     encapsulation=yes

The Site Office configuration

conn PLSUBNET
     also=PLUTO-EUROPA
     leftsubnet=10.10.128.0/24
     leftsourceip=10.10.128.100
     rightsubnet=192.168.1.0/24
     rightsourceip=192.168.1.1
     auto=start
conn PLUTO-EUROPA
     type=tunnel
     left=%defaultroute
     leftid=W.X.Y.Z
     right=A.B.C.D
     authby=secret
     ikev2=insist
     pfs=no
     ike=aes256-sha2_512+sha2_256-dh21
     esp=aes256-sha2_512+sha1+sha2_256;dh21
     dpddelay=5
     dpdtimeout=120
     dpdaction=restart
     encapsulation=yes

The Logs from the HO machine

980030: "PLUTOSUBNET" #8: STATE_PARENT_I1: retransmission; will wait 16 
seconds for response
984155: "PLUTOSUBNET" #8: STATE_PARENT_I1: retransmission; will wait 32 
seconds for response
634277: "PLUTOSUBNET" #9: proposal 
1:IKE=AES_CBC_256-HMAC_SHA2_512-HMAC_SHA2_512_256-ECP_521 chosen from 
remote proposals 
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;DH=ECP_521[first-match]
636046: "PLUTOSUBNET" #9: sent IKE_SA_INIT reply {auth=IKEv2 
cipher=AES_CBC_256 integ=HMAC_SHA2_512_256 prf=HMAC_SHA2_512 group=DH21}
"PLUTOSUBNET" #9: processing decrypted IKE_AUTH request: 
SK{IDi,AUTH,SA,TSi,TSr}
"PLUTOSUBNET" #9: IKEv2 mode peer ID is ID_IPV4_ADDR: 'W.X.Y.Z'
"PLUTOSUBNET" #9: authenticated using authby=secret
"PLUTOSUBNET": local ESP/AH proposals (IKE_AUTH responder matching 
remote ESP/AH proposals):
"PLUTOSUBNET":   
1:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA1_96+HMAC_SHA2_256_128-NONE-DISABLED
"PLUTOSUBNET" #10: proposal 1:ESP=AES_CBC_256-HMAC_SHA2_512_256-DISABLED 
SPI=cff38461 chosen from remote proposals 
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA1_96;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]
"PLUTOSUBNET" #10: negotiated connection 
[192.168.1.0-192.168.1.255:0-65535 0] -> 
[10.10.128.0-10.10.128.255:0-65535 0]
"PLUTOSUBNET" #10: IPsec SA established tunnel mode 
{ESPinUDP=>0xcff38461 <0x51123a6c xfrm=AES_CBC_256-HMAC_SHA2_512_256 
NATOA=none NATD=W.X.Y.Z:4500 DPD=active}
"PLUTOSUBNET" #8: suppressing retransmit because IKE SA was superseded 
#9 try=4; drop this negotiation
"PLUTOSUBNET" #8: deleting state (STATE_PARENT_I1) aged 64.012686s and 
NOT sending notification

Any help please.

Thanks, BA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20230129/57a0bc4d/attachment.htm>

From paul at nohats.ca  Mon Jan 30 02:59:51 2023
From: paul at nohats.ca (Paul Wouters)
Date: Sun, 29 Jan 2023 19:59:51 -0500 (EST)
Subject: [Swan] [SPAM: 4.729] Tunnel gets established,
 but machines can reach each other only for less than a minute
In-Reply-To: <e98b098de24169ed6e8eee9cbb2f1d37@blueaquan.com>
References: <e98b098de24169ed6e8eee9cbb2f1d37@blueaquan.com>
Message-ID: <0afaab30-d5cc-d942-f12a-45e1ac7fc13a@nohats.ca>

On Sun, 29 Jan 2023, ud at blueaquan.com wrote:

> I have two sites which I am trying to connect using a site-to-site VPN. ?Initially I had a lot of
> challenges because at the HO, the Linux machine had a Public IP directly configured, while at the
> Site Office the Linux machine was behind an ISP router. Anyhow the tunnel gets established now, but
> machines on both sides cannot reach each other.

On the HO use auto=add and not auto=ondemand or auto=start
On the Site Office, use auto=start

That should hopefully prevent two connections racing each other
and one of them failing impacting the other.

> The HO Configuration
> 
> conn PLUTOSUBNET
> 	also=EUROPA-PLUTO
> 	leftsubnet=10.10.128.0/24
> 	leftsourceip=10.10.128.100
> 	rightsubnet=192.168.1.0/24
> 	rightsourceip=192.168.1.1
> 	auto=start

you cannot use auto=start because you cannot initiate to a machine
behind NAT. The other end should initiate to here.

> 	encapsulation=yes

It's better not to specify this and let the auto-detection handle this.

> The Site Office configuration
> 
> conn PLSUBNET
> 	also=PLUTO-EUROPA
> 	leftsubnet=10.10.128.0/24
> 	leftsourceip=10.10.128.100
> 	rightsubnet=192.168.1.0/24
> 	rightsourceip=192.168.1.1
> 	auto=start
> conn PLUTO-EUROPA
> 	type=tunnel
> 	left=%defaultroute
> 	leftid=W.X.Y.Z
> 	right=A.B.C.D
> 	authby=secret
> 	ikev2=insist
> 	pfs=no
> 	ike=aes256-sha2_512+sha2_256-dh21
> 	esp=aes256-sha2_512+sha1+sha2_256;dh21
> 	dpddelay=5
> 	dpdtimeout=120
> 	dpdaction=restart
> 	encapsulation=yes

Same here, remove the encapsulation=yes here too.

> The Logs from the HO machine

> 980030: "PLUTOSUBNET" #8: STATE_PARENT_I1: retransmission; will wait 16 seconds for response
> 984155: "PLUTOSUBNET" #8: STATE_PARENT_I1: retransmission; will wait 32 seconds for response
> 634277: "PLUTOSUBNET" #9: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_512-HMAC_SHA2_512_256-ECP_521 chosen f

Looks like state 8 and 9 are fighting here.

> "PLUTOSUBNET" #10: negotiated connection [192.168.1.0-192.168.1.255:0-65535 0] -> [10.10.128.0-10.10.
> 128.255:0-65535 0]
> "PLUTOSUBNET" #10: IPsec SA established tunnel mode {ESPinUDP=>0xcff38461 <0x51123a6c xfrm=AES_CBC_25
> 6-HMAC_SHA2_512_256 NATOA=none NATD=W.X.Y.Z:4500 DPD=active}
> "PLUTOSUBNET" #8: suppressing retransmit because IKE SA was superseded #9 try=4; drop this negotiatio
> n
> "PLUTOSUBNET" #8: deleting state (STATE_PARENT_I1) aged 64.012686s and NOT sending notification

9 won and 8 was deleted. This _should_ be fine. But perhaps the other
end did something different.

Paul

From ud at blueaquan.com  Mon Jan 30 07:32:19 2023
From: ud at blueaquan.com (ud at blueaquan.com)
Date: Mon, 30 Jan 2023 11:02:19 +0530
Subject: [Swan] [SPAM: 4.729] Re:  Tunnel gets established,
 but machines can reach each other only for less than a minute
In-Reply-To: <0afaab30-d5cc-d942-f12a-45e1ac7fc13a@nohats.ca>
References: <e98b098de24169ed6e8eee9cbb2f1d37@blueaquan.com>
 <0afaab30-d5cc-d942-f12a-45e1ac7fc13a@nohats.ca>
Message-ID: <9f41cbaaf42addecbf6254d1a35b7de2@blueaquan.com>


Hi Paul
I changed the HO's statement to auto=add while keeping auto=start at the 
Site Office. Also removed encapsulation statement at both ends, However 
there is no change in status, both machines are unable to reach each 
other. The tunnel is getting established as always, attaching the logs 
from both sides FYI.

At Site Office

643271: "PLSUBNET" #1: initiating IKEv2 connection
643284: "PLSUBNET": local IKE proposals (IKE SA initiator selecting KE):
643290: "PLSUBNET":   
1:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-ECP_521
645097: "PLSUBNET" #1: sent IKE_SA_INIT request
685003: "PLSUBNET": local ESP/AH proposals (IKE SA initiator emitting 
ESP/AH proposals):
685026: "PLSUBNET":   
1:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA1_96+HMAC_SHA2_256_128-NONE-DISABLED
685066: "PLSUBNET" #1: sent IKE_AUTH request {auth=IKEv2 
cipher=AES_CBC_256 integ=HMAC_SHA2_512_256 prf=HMAC_SHA2_512 group=DH21}
760199: "PLSUBNET" #1: authenticated using authby=secret and peer 
ID_IPV4_ADDR 'A.B.C.D'
797979: "PLSUBNET" #2: negotiated connection 
[10.10.128.0-10.10.128.255:0-65535 0] -> 
[192.168.1.0-192.168.1.255:0-65535 0]
798003: "PLSUBNET" #2: IPsec SA established tunnel mode 
{ESPinUDP=>0xf326adb4 <0x3227b8ff xfrm=AES_CBC_256-HMAC_SHA2_512_256 
NATOA=none NATD=A.B.C.D:4500 DPD=active}

At HO

657566: "PLUTOSUBNET": local IKE proposals (IKE SA responder matching 
remote proposals):
657597: "PLUTOSUBNET":   
1:IKE=AES_CBC_256-HMAC_SHA2_512+HMAC_SHA2_256-HMAC_SHA2_512_256+HMAC_SHA2_256_128-ECP_521
657625: "PLUTOSUBNET" #8: proposal 
1:IKE=AES_CBC_256-HMAC_SHA2_512-HMAC_SHA2_512_256-ECP_521 chosen from 
remote proposals 
1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_512;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA2_256_128;DH=ECP_521[first-match]
659422: "PLUTOSUBNET" #8: sent IKE_SA_INIT reply {auth=IKEv2 
cipher=AES_CBC_256 integ=HMAC_SHA2_512_256 prf=HMAC_SHA2_512 group=DH21}
705240: "PLUTOSUBNET" #8: processing decrypted IKE_AUTH request: 
SK{IDi,AUTH,SA,TSi,TSr}
705270: "PLUTOSUBNET" #8: IKEv2 mode peer ID is ID_IPV4_ADDR: 'W.X.Y.Z'
705323: "PLUTOSUBNET" #8: authenticated using authby=secret
705429: "PLUTOSUBNET": local ESP/AH proposals (IKE_AUTH responder 
matching remote ESP/AH proposals):
705438: "PLUTOSUBNET":   
1:ESP=AES_CBC_256-HMAC_SHA2_512_256+HMAC_SHA1_96+HMAC_SHA2_256_128-NONE-DISABLED
705445: "PLUTOSUBNET" #9: proposal 
1:ESP=AES_CBC_256-HMAC_SHA2_512_256-DISABLED SPI=3227b8ff chosen from 
remote proposals 
1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_512_256;INTEG=HMAC_SHA1_96;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]
741491: "PLUTOSUBNET" #9: negotiated connection 
[192.168.1.0-192.168.1.255:0-65535 0] -> 
[10.10.128.0-10.10.128.255:0-65535 0]
741513: "PLUTOSUBNET" #9: IPsec SA established tunnel mode 
{ESPinUDP=>0x3227b8ff <0xf326adb4 xfrm=AES_CBC_256-HMAC_SHA2_512_256 
NATOA=none NATD=W.X.Y.Z:4500 DPD=active}

Thanks, Regards

BA

On 2023-01-30 06:29, Paul Wouters wrote:

> On Sun, 29 Jan 2023, ud at blueaquan.com wrote:
> 
>> I have two sites which I am trying to connect using a site-to-site 
>> VPN.  Initially I had a lot of
>> challenges because at the HO, the Linux machine had a Public IP 
>> directly configured, while at the
>> Site Office the Linux machine was behind an ISP router. Anyhow the 
>> tunnel gets established now, but
>> machines on both sides cannot reach each other.
> 
> On the HO use auto=add and not auto=ondemand or auto=start
> On the Site Office, use auto=start
> 
> That should hopefully prevent two connections racing each other
> and one of them failing impacting the other.
> 
>> The HO Configuration
>> 
>> conn PLUTOSUBNET
>> also=EUROPA-PLUTO
>> leftsubnet=10.10.128.0/24
>> leftsourceip=10.10.128.100
>> rightsubnet=192.168.1.0/24
>> rightsourceip=192.168.1.1
>> auto=start
> 
> you cannot use auto=start because you cannot initiate to a machine
> behind NAT. The other end should initiate to here.
> 
>> encapsulation=yes
> 
> It's better not to specify this and let the auto-detection handle this.
> 
>> The Site Office configuration
>> 
>> conn PLSUBNET
>> also=PLUTO-EUROPA
>> leftsubnet=10.10.128.0/24
>> leftsourceip=10.10.128.100
>> rightsubnet=192.168.1.0/24
>> rightsourceip=192.168.1.1
>> auto=start
>> conn PLUTO-EUROPA
>> type=tunnel
>> left=%defaultroute
>> leftid=W.X.Y.Z
>> right=A.B.C.D
>> authby=secret
>> ikev2=insist
>> pfs=no
>> ike=aes256-sha2_512+sha2_256-dh21
>> esp=aes256-sha2_512+sha1+sha2_256;dh21
>> dpddelay=5
>> dpdtimeout=120
>> dpdaction=restart
>> encapsulation=yes
> 
> Same here, remove the encapsulation=yes here too.
> 
>> The Logs from the HO machine
> 
>> 980030: "PLUTOSUBNET" #8: STATE_PARENT_I1: retransmission; will wait 
>> 16 seconds for response
>> 984155: "PLUTOSUBNET" #8: STATE_PARENT_I1: retransmission; will wait 
>> 32 seconds for response
>> 634277: "PLUTOSUBNET" #9: proposal 
>> 1:IKE=AES_CBC_256-HMAC_SHA2_512-HMAC_SHA2_512_256-ECP_521 chosen f
> 
> Looks like state 8 and 9 are fighting here.
> 
>> "PLUTOSUBNET" #10: negotiated connection 
>> [192.168.1.0-192.168.1.255:0-65535 0] -> [10.10.128.0-10.10.
>> 128.255:0-65535 0]
>> "PLUTOSUBNET" #10: IPsec SA established tunnel mode 
>> {ESPinUDP=>0xcff38461 <0x51123a6c xfrm=AES_CBC_25
>> 6-HMAC_SHA2_512_256 NATOA=none NATD=W.X.Y.Z:4500 DPD=active}
>> "PLUTOSUBNET" #8: suppressing retransmit because IKE SA was superseded 
>> #9 try=4; drop this negotiatio
>> n
>> "PLUTOSUBNET" #8: deleting state (STATE_PARENT_I1) aged 64.012686s and 
>> NOT sending notification
> 
> 9 won and 8 was deleted. This _should_ be fine. But perhaps the other
> end did something different.
> 
> Paul
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.libreswan.org/pipermail/swan/attachments/20230130/6fe861bc/attachment.htm>