FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
980 views 2 comments
by
I configured a TRB140 for a IPSEC IKEv1 tunnel with a Draytek router. Everything is working fine the first few hours but at some point the dataconnection isn't working anymore. Status of VPN connection in Draytek and TRB140 are still UP and connected. The only way I can solve this is by executing "ipsec restart" in the TRB140.

Result of ipsec statusall when no data connection is possible:

root@TRB140-BlutchS:~# ipsec statusall
Status of IKE charon daemon (strongSwan 5.8.0, Linux 3.18.20-msm, armv7l):
  uptime: 4 hours, since Apr 17 07:52:59 2020
  malloc: sbrk 765952, mmap 0, used 532608, free 233344
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 12
  loaded plugins: charon aes des rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gmp curve25519 xcbc cmac hmac curl sqlite attr kernel-netlink resolve socket-default stroke vici updown xauth-generic
Listening IP addresses:
  100.96.51.153
  172.20.1.254
Connections:
Blutch-Blutch_c:  %any...123.123.123.123  IKEv1 Aggressive, dpddelay=30s
Blutch-Blutch_c:   local:  [Customer001] uses pre-shared key authentication
Blutch-Blutch_c:   remote: [123.123.123.123] uses pre-shared key authentication
Blutch-Blutch_c:   child:  172.20.1.0/24 === 192.168.1.0/24 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):
Blutch-Blutch_c[5]: ESTABLISHED 93 minutes ago, 100.96.51.153[NeoPix001]...123.123.123.123[123.123.123.123]
Blutch-Blutch_c[5]: IKEv1 SPIs: a6d987df295hh0ff_i* 03c8a8186273081b_r, pre-shared key reauthentication in 6 hours
Blutch-Blutch_c[5]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
Blutch-Blutch_c{9}:  REKEYED, TUNNEL, reqid 5, expires in 11 minutes
Blutch-Blutch_c{9}:   172.20.1.0/24 === 192.168.1.0/24
Blutch-Blutch_c{10}:  INSTALLED, TUNNEL, reqid 5, ESP in UDP SPIs: c3b962e3_i 70d526a9_o
Blutch-Blutch_c{10}:  AES_CBC_128/HMAC_SHA1_96/MODP_1536, 0 bytes_i, 0 bytes_o, rekeying in 39 minutes
Blutch-Blutch_c{10}:   172.20.1.0/24 === 192.168.1.0/24

1 Answer

0 votes
by anonymous
Hello,

Couple of questions, first does other devices keep connection with yours Drayek router indefinitely? Secondly do you have Dead Peer Protection and keepalive enabled?

Maybe you could post yours VPN configuration here?

Best regards,
VidasKac
by

Hi,

Thank you for your reply!
Other devices don't keep there connection indefinitely but they reconnect when no data connection is possible. It seems that the TRB140 doesn't detect when the dataconnection is lost(connection state at this point is on both sides "connected").

I have tried with and without Dead peer detection but this doesn't work for this issue.

The VPN configuration is:

# generated by /etc/init.d/ipsec
version 2

conn Blutch-Blutch_c
  left=%any
  right=123.123.123.123
  leftsubnet=172.20.1.0/24
  leftfirewall=no
  rightfirewall=no
  ikelifetime=8h
  lifetime=1h
  margintime=9m
  keyingtries=3
  dpdaction=restart
  dpddelay=30s
  inactivity=30s
  leftauth=psk
  rightauth=psk
  rightsubnet=192.168.1.0/24
  auto=start
  leftid=Customer001
  rightid=123.123.123.123
  forceencaps=no
  keyexchange=ikev1
  esp=aes128-sha1-modp1536
  ike=aes128-sha1-modp1536
  aggressive=yes
  type=tunnel

I will replace the Draytek for a new one to be sure this isn't the cause of the issue

by anonymous

So as I understand at first tunnel connects and is working fine, but if TRB looses internet access it does not drop tunnel, (but it also does not disconnect at Draytek side?) so after connection resumes Ipsec does not restart, and even though it is shown as connected there is no access?

Would it be possible for you to send me a troubleshoot file after simulating the problem, so we could take deeper look into that?

And for time being you could try using ping reboot script:

#!/bin/ash
while [ 1 ]; do
ping [Draytek_IP] -c 3 -q >/dev/null
ret=$?
if [ $ret -ne 0 ]; then
/etc/init.d/ipsec restart
fi
sleep 60
done

To make it run on boot add /<script_directory>/<script_name.sh> to /etc/rc.local it should check VPN connection every minute (unless you set it for different time) and restart it.