IPsec site to site VPN - Connected but no data

NETWORKING SOLUTIONS
1

Hi, we have a TRB140 on latest firmware (7.10.2), we are trying to get 3 IPsec site to site VPN’s to work, they all show as connected by we are unable to communicate with any of the other networks. The 3 VPN’s are all IPsec IKEv2, the 3 routers we are connecting to are all different and have VPN’s to other sites working fine (SonicWALL, MikroTik, Azure).

I have performed another factory reset, all I have changed is the LAN subnet from the default of 192.168.2.0/24 to 192.168.35.0/24, and then add the VPN’s in services / VPN / IPsec. Are there any other settings that need to be set. I can see it has automatically added a static route and a Source NAT rule called Exclude-IPsec-from-NAT.

Screenshot 2024-11-20 104748
Screenshot 2024-11-20 104748966×544 19.6 KB

Screenshot 2024-11-20 104756
Screenshot 2024-11-20 104756956×589 21.4 KB

Screenshot 2024-11-20 104807
Screenshot 2024-11-20 1048071012×591 24.5 KB

Screenshot 2024-11-20 104814
Screenshot 2024-11-20 104814850×482 11.5 KB

2

Hello,

Would it be possible to see the output of ipsec statusall on the TRB ? On the devices at the other ends ?

Regards,

3

Hi, below are the output for ipsec statusall. If you still need output from the other ends I would need to do that on Monday when I am in the office, all the other ends are not Teltonika. Thanks

root@TRB140:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.9.14, Linux 5.4.282, armv7l):
uptime: 115 seconds, since Nov 23 13:11:24 2024
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 8
loaded plugins: charon des sha1 md4 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pgp pem ope
nssl pkcs8 xcbc kernel-netlink socket-default connmark stroke vici updown eap-identity eap-mschapv2 xauth-ge
neric
Listening IP addresses:
192.168.35.254
XXX.XXX.XXX.138
Connections:
VPN1_c: %any…XXX.XXX.XXX.215 IKEv2
VPN1_c: local: [XXX.XXX.XXX.138] uses pre-shared key authentication
VPN1_c: remote: [XXX.XXX.XXX.215] uses pre-shared key authentication
VPN1_c: child: 192.168.35.0/24 === 10.255.0.0/21 TUNNEL
VPN2_c: %any…XXX.XXX.XXX.6 IKEv2
VPN2_c: local: [XXX.XXX.XXX.138] uses pre-shared key authentication
VPN2_c: remote: [XXX.XXX.XXX.6] uses pre-shared key authentication
VPN2_c: child: 192.168.35.0/24 === 192.168.1.0/24 TUNNEL
VPN3_c: %any…XXX.XXX.XXX.227 IKEv2
VPN3_c: local: uses pre-shared key authentication
VPN3_c: remote: [XXX.XXX.XXX.227] uses pre-shared key authentication
VPN3_c: child: 192.168.35.0/24 === 192.168.11.0/24 TUNNEL
Security Associations (4 up, 0 connecting):
VPN3_c[4]: ESTABLISHED 96 seconds ago, XXX.XXX.XXX.138[XXX.XXX.XXX.138]…XXX.XXX.XXX.227[XXX.XXX.XXX.227
]
VPN3_c[4]: IKEv2 SPIs: 841991b5c3c1d418_i a681db93b7fc1b39_r*, pre-shared key reauthentication in
7 hours
VPN3_c[4]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
VPN3_c{4}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c3268bd6_i bcc050eb_o
VPN3_c{4}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
VPN3_c{4}: 192.168.35.0/24 === 192.168.11.0/24
VPN3_c[3]: ESTABLISHED 94 seconds ago, XXX.XXX.XXX.138[XXX.XXX.XXX.138]…XXX.XXX.XXX.227[XXX.XXX.XXX.227
]
VPN3_c[3]: IKEv2 SPIs: 3e0bfd3440cb3a2d_i* 5578222e48af21aa_r, pre-shared key reauthentication in
7 hours
VPN3_c[3]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
VPN3_c{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c2153903_i 4dd8565d_o
VPN3_c{2}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 153288 bytes_o (2737 pkts, 2s ago), rekeyin
g in 7 hours
VPN3_c{2}: 192.168.35.0/24 === 192.168.11.0/24
VPN2_c[2]: ESTABLISHED 94 seconds ago, XXX.XXX.XXX.138[XXX.XXX.XXX.138]…XXX.XXX.XXX.6[XXX.XXX.XXX.6]
VPN2_c[2]: IKEv2 SPIs: 7fc3b0163406f8ae_i* 0a6c3c6358d05f9f_r, pre-shared key reauthentication in
7 hours
VPN2_c[2]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
VPN2_c{3}: INSTALLED, TUNNEL, reqid 3, ESP SPIs: ce39e7b1_i 04cb8aa6_o
VPN2_c{3}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
VPN2_c{3}: 192.168.35.0/24 === 192.168.1.0/24
VPN1_c[1]: ESTABLISHED 94 seconds ago, XXX.XXX.XXX.138[XXX.XXX.XXX.138]…XXX.XXX.XXX.215[XXX.XXX.XXX.215
]
VPN1_c[1]: IKEv2 SPIs: c7dc35d6c5cdee8e_i* d9fc48fc9685c8f1_r, pre-shared key reauthentication in 7
hours
VPN1_c[1]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
VPN1_c{1}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: ccac70f9_i b64c35ea_o
VPN1_c{1}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 0 bytes_o, rekeying in 7 hours
VPN1_c{1}: 192.168.35.0/24 === 10.255.0.0/21
root@TRB140:~#

4

Yes. And when you mask public IP addresses use publicip1 publicip2 … the XXX.XXX etc are hard to follow.

From the TRB, ping a remote device. Check with ipsec statusall the bytes_i and bytes_o counter at both ends. If bytes_o increases the echo request goes through the tunnel then check the bytes_i counter at the destination. Does it increase ? Same for the other way around.

5 
VPN3_c{2}: AES_CBC_256/HMAC_SHA2_256_128, 0 bytes_i, 153288 bytes_o (2737 pkts, 2s ago), rekeying in 7 hours

At least this one does something. What do you have at the remote end ?