strongSwan

Please only consider chreosistunnel related log entries. The rest is transport mode connections and unrelated.

Tobias Brunner wrote:

The IKE daemon charon only tracks two concurrent Quick Mode exchanges by default. Since the last QM messages of all five exchanges arrive after all initial messages have been handled, the state of the first three has already been replaced, however, these messages again will replace the states so even the last two exchanges can't be completed successfully. You can increase the number of states to track at source:src/libcharon/sa/ikev1/keymat_v1.c#L30.

Hi Tobias, thanks.

That makes a lot of sense. Will it be possible to expose these variable to the config? Should I open a new ticket for that?

I'm quickly building and testing with the changed parameters. If this solves my issue, I will close it.

I've tested and all are now established:

chreosistunnel:  172.30.0.143...196.34.134.31  IKEv1/2, dpddelay=120s
chreosistunnel:   local:  [54.228.251.166] uses pre-shared key authentication
chreosistunnel:   remote: [196.34.134.31] uses pre-shared key authentication
chreosistunnel:   child:  10.152.0.0/16 === 196.35.194.232/32 196.35.194.161/32 196.35.194.171/32 196.35.194.188/32 196.35.194.183/32 TUNNEL, dpdaction=clear
chreosistunnel{132}:  ROUTED, TUNNEL, reqid 130
chreosistunnel{132}:   10.152.0.0/16 === 196.35.194.161/32 196.35.194.171/32 196.35.194.183/32 196.35.194.188/32 196.35.194.232/32 
chreosistunnel[15]: ESTABLISHED 111 seconds ago, 172.30.0.143[54.228.251.166]...196.34.134.31[196.34.134.31]
chreosistunnel[15]: IKEv1 SPIs: 93c7b2f5c89f6435_i 8815e1008f5bd2fd_r*, pre-shared key reauthentication in 7 hours
chreosistunnel[15]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
chreosistunnel{1}:  INSTALLED, TUNNEL, reqid 1, ESP in UDP SPIs: ce736eeb_i 7b1de0d8_o
chreosistunnel{1}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{1}:   10.152.0.0/16 === 196.35.194.171/32 
chreosistunnel{2}:  INSTALLED, TUNNEL, reqid 2, ESP in UDP SPIs: c31f6a4d_i 7b1de0d9_o
chreosistunnel{2}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{2}:   10.152.0.0/16 === 196.35.194.183/32 
chreosistunnel{3}:  INSTALLED, TUNNEL, reqid 3, ESP in UDP SPIs: c750ec19_i 7b1de0da_o
chreosistunnel{3}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{3}:   10.152.0.0/16 === 196.35.194.232/32 
chreosistunnel{4}:  INSTALLED, TUNNEL, reqid 4, ESP in UDP SPIs: c17372e5_i 7b1de0db_o
chreosistunnel{4}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{4}:   10.152.0.0/16 === 196.35.194.161/32 
chreosistunnel{5}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: cc4559f9_i 7b1de0dc_o
chreosistunnel{5}:  3DES_CBC/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
chreosistunnel{5}:   10.152.0.0/16 === 196.35.194.188/32 

I've called

sudo ipsec route chreosistunnel
sudo ip route list table 220

The table shows:

196.35.194.161 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.171 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.183 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.188 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 
196.35.194.232 via 172.30.0.1 dev eth0  proto static  src 10.152.1.1 

However,

sudo traceroute -s 10.152.1.1 196.35.194.161 #or any of the connected CHILD_SA's#

Will it be possible to expose these variable to the config?

Please have a look at the 1128-qm-max branch and #1128. Before 5.3.3 this client behavior would actually have resulted in other failures (see #1076).

Doesn't get routed through the tunnel.

Is this traffic just blocked? Or sent unencrypted? You might have to set lefthostaccess=yes if you use leftfirwall=yes with a DROP policy for the INPUT/OUTPUT chain.

Tobias Brunner wrote:

this traffic just blocked? Or sent unencrypted? You might have to set lefthostaccess=yes if you use leftfirwall=yes with a DROP policy for the INPUT/OUTPUT chain.

The traffic is sent unencrypted through eth0, and doesn't get affected by the installed policy or ip routing table.
I have masquerading enabled for the transport connections

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  10.152.0.0/16        0.0.0.0/0            policy match dir out pol ipsec
MASQUERADE  all  --  10.152.0.0/16        0.0.0.0/0 

These connections "chreosis connection" should use the VPN 10.152.1.1 as gateway except for traffic destined for the tunnel CHILD_SA's which should route through the tunnel. Again this used to work with 5.1.2.

Probably due to mark=%unique. As you will see in the output of ip xfrm policy the policies will have a mark assigned, which means packets only match them if they also are marked accordingly. Unless you actually use this mark for something (e.g. mark traffic via iptables) just remove it.

Tobias Brunner wrote:

Probably due to mark=%unique. As you will see in the output of ip xfrm policy the policies will have a mark assigned, which means packets only match them if they also are marked accordingly. Unless you actually use this mark for something (e.g. mark traffic via iptables) just remove it.

The client tunnel connection also serves as a NAT for devices using it as a gateway for a private APN. If unique isn't needed to support multiple clients from the same NAT, then it should be fine.

Pieter Jordaan wrote:

Tobias Brunner wrote:

Probably due to mark=%unique. As you will see in the output of ip xfrm policy the policies will have a mark assigned, which means packets only match them if they also are marked accordingly. Unless you actually use this mark for something (e.g. mark traffic via iptables) just remove it.

The client tunnel connection also serves as a NAT for devices using it as a gateway for a private APN. If unique isn't needed to support multiple clients from the same NAT, then it should be fine.

I can confirm it does in fact work. This did NOT work in 5.1.2, but the fix in 5.3.0 regarding the NAT issue resolved this. Not the mark=%unique. I can confirm everything works as expected now.

Thanks for your support and awesome software