ммм. и откуда трафик льется?

root@vpntest-us:~/vpnserver# ps ax|grep vpn
  3333 ?        S<s    0:00 /root/vpnserver/vpnserver execsvc
  3334 ?        S<l    0:01 /root/vpnserver/vpnserver execsvc

namespaces? vrf?

нет ничего такого

я же говорю там userspace tcp

так не бывает

root@vpntest-us:~/vpnserver# tail server_log/vpn_20200731.log
2020-07-31 12:41:07.965 [HUB "VPN"] SecureNAT: The UDP session 65 has been created. Connection source 192.168.11.10:53671, Connection destination 142.250.66.202:443
2020-07-31 12:41:17.230 [HUB "VPN"] SecureNAT: The UDP session 66 has been created. Connection source 192.168.11.10:53674, Connection destination 255.255.255.255:1900
2020-07-31 12:41:18.548 [HUB "VPN"] SecureNAT: The UDP session 67 has been created. Connection source 192.168.11.10:49382, Connection destination 192.168.11.1:53
2020-07-31 12:41:18.873 [HUB "VPN"] SecureNAT: The TCP session 68 has been created. Connection source 192.168.11.10:53732, Connection destination 40.119.211.203:443
2020-07-31 12:41:55.713 [HUB "VPN"] SecureNAT: The UDP session 62 has been deleted.

бывает :)

не бывает

тут не о чем спорить

трафик должен как-то инжектиться в стек, обычный способ без доп интерфейсов - у ipsec-а со входящего интерфейса по политике

тут юзерспейс. раншьше трафик скидывался через tun драйвер

а покажи маршруты

https://www.softether.org/4-docs/1-manual/2._SoftEther_VPN_Essential_Architecture/2.1_VPN_Communication_Protocol
пункт 2.1.1

root@vpntest-us:~/vpnserver# ip r
default via 45.77.208.1 dev ens3 proto dhcp src 45.77.209.162 metric 100
10.100.1.0/24 dev ztyxauhvvi proto kernel scope link src 10.100.1.211
45.77.208.0/23 dev ens3 proto kernel scope link src 45.77.209.162
169.254.169.254 via 45.77.208.1 dev ens3 proto dhcp src 45.77.209.162 metric 100

он же и нат сам делает

это у них новая функция SecureNAT

можно настроить через обычный bridge и выдавать самому dhcp делать нат через ядро и т.д.

это не про sstp

но зачем? в данном случае оно точно работает и точно нет интерфейса