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, [email protected] 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
_______________________________________________
Swan mailing list
[email protected]
https://lists.libreswan.org/mailman/listinfo/swan
