Dead-peer-detection (IPSEC/L2TP with RADIUS on WIN2019 Server - part2)

General questions
1

Hi there,

Would you please point out configuration files responsible for processing below code

[code]vpn {
ipsec {
auto-update 60
ike-group IKE-1 {
close-action clear
dead-peer-detection {
action clear
interval 30
timeout 60
}
…
}
…

}
[/code]
Have found suspicious behavior on the L2TP/IPSEC firewall - configuration with RADIUS authentication does not clear dead IPSEC tunnels.
More or less same configuration without RADIUS clears tunnels without problem.

Thanks

2

Hi, this one /etc/ipsec.d/tunnels/remote-access

1 Like
3

Thanks, Dmitry.

It seems configuration is correct in both cases.
Even more, i’ve found the task on the working L2TP gateway arranged to restart the vpn every night

    task-scheduler {
        task reboot-vpn {
            crontab-spec "23 23 * * *"
            executable {
                path /config/scripts/reboot-vpn.sh
            }
        }
    }

Problem seems in IPSEC dead tunnels, I recalled it is very old problem.

~$ show vpn ipsec sa
Connection     State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID      Proposal
-------------  -------  --------  --------------  ----------------  ----------------  -------------  ------------------------
remote-access  up       1h41m35s  3M/3M           32K/31K           <external IP1>      192.168.1.43   AES_CBC_256/HMAC_SHA1_96
remote-access  up       1h54m59s  1M/2M           14K/13K           <external IP2>     192.168.0.100  AES_CBC_256/HMAC_SHA1_96

Such tunnels could hung for 1/2/3 days and prevent the relogin from the same IP address.
cron task at night clears non-active tunnels.
But I expected deap-peer-action clear did so.

Any idea/comment/feedback is welcome.

4

So, I think dead-peer-detection should solve this issue, isn’t it?
Can you disable this cron-rule and check sudo swanctl -l whet it happened?
ps:// Please mark your public ip addresses.

5

So, I think dead-peer-detection should solve this issue, isn’t it?

Yes, i just forgot about fix by task.
But it seems very old problem, since very previois version - half year ago or even more/

Can you disable this cron-rule and check sudo swanctl -l whet it happened?

It could be possible with next few days, because it very occational event.
Need collect some load activity from our workers.

ps:// Please mark your public ip addresses.

thanks, did it

6

HI!
Bump up quite old theme

Have a hung tunnel for about 6 hours

vyos@vyos-fwl:~$  show vpn remote-access
ifname | username | calling-sid | ip | rate-limit | type | comp | state | rx-bytes | tx-bytes | uptime
--------+----------+-------------+----+------------+------+------+-------+----------+----------+--------
vyos@vyos-fwl:~$  show vpn ipsec sa
Connection     State    Uptime    Bytes In/Out    Packets In/Out    Remote address    Remote ID      Proposal
-------------  -------  --------  --------------  ----------------  ----------------  -------------  ------------------------
remote-access  up       6h6m19s   2M/23M          16K/21K           <client-ip>    192.168.0.108  AES_CBC_256/HMAC_SHA1_96
vyos@vyos-fwl:~$ sudo swanctl -l
remote-access: #15, ESTABLISHED, IKEv1, 210031af1c194476_i 785d64c62a92d88d_r*
  local  '<server-ip>' @ <server-ip>[4500]
  remote '192.168.0.108' @ <client-ip>[4500]
  3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024
  established 22013s ago
  remote-access: #12, reqid 12, REKEYED, TRANSPORT-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
    installed 33067s ago
    in  cdff88b4 (0x0000000b), 365202 bytes,  2362 packets
    out 0fb25898, 1238518 bytes,  2754 packets, 17151s ago
    local  <server-ip>/32[udp/l2f]
    remote <client-ip>/32[udp/l2f]
  remote-access: #14, reqid 12, REKEYED, TRANSPORT-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
    installed 25068s ago
    in  c22a2662 (0x0000000b), 32255648 bytes, 37161 packets
    out c412dcf6, 6120185 bytes, 24693 packets, 17151s ago
    local  <server-ip>/32[udp/l2f]
    remote <client-ip>/32[udp/l2f]
  remote-access: #16, reqid 12, INSTALLED, TRANSPORT-in-UDP, ESP:AES_CBC-256/HMAC_SHA1_96
    installed 18668s ago
    in  c983fb3c (0x0000000b), 3041752 bytes, 16782 packets
    out c2e0cb6e, 24501351 bytes, 21816 packets, 17151s ago
    local  <server-ip>/32[udp/l2f]
    remote <client-ip>/32[udp/l2f]
vyos@vyos-fwl:~$
7

Hi @hook.ua, it looks like the IPSec session alive because Win clients do not support DPD. And IPSec session should be dropped on rekeying only.
I can confirm that this does not happen when client Mac OS X.
In VyOS logs you can find the following output

charon[5798]: 08[IKE] DPD not supported by peer, disabled
8

Hi, Dmitry.

Sorry, missed this thread for a while.

Yes, I would confirm - mentioned string present in log for almost every windows client connection.
So, it seems, nightly reset of IPSEC/VPN is descent solution in windows-rich environment.

Thanks for your support.