[Swan] [SPAM: 4.729] Re: Tunnel gets established, but machines can reach each other only for less than a minute

Mon Jan 30 07:32:19 EET 2023

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>