VPN IPSec com Libreswan, mas sem tráfego através do túnel

Question

Tenho algumas conexões VPN para alguns destinos. Um deles é IPSEC IKEv1 usando Libreswan no lado do cliente. O cliente é um "guerreiro da estrada". O servidor VPN funciona - eu posso conectar-me com sucesso ao Windows (Screwsoft-Client).

Eu joguei muito com a configuração e cheguei a isso:

config setup
protostack  =   netkey

conn Office1
authby      =   secret
right       =   some.domain.tld
rightid     =   @Office_admin
rightnexthop    =   %defaultroute
left        =   192.168.42.91
leftsubnet  =   192.168.92.0/24
leftvti     =   192.168.92.234/24
leftid      =   @Office
keyexchange =   ike
ike     =   aes256-sha2;modp2048
esp     =   aes256-sha2;modp2048
ikelifetime =   4h
keylife     =   8h
auto        =   add
aggrmode    =   yes
vti-interface = vti0
vti-routing =   yes
mark        =   5/0xffffffff

Ele se conecta e aparece, essa conexão está ligada! Bem!

003 "Office1": IKEv1 Aggressive Mode with PSK is vulnerable to dictionary attacks and is cracked on large scale by TLA's 
002 "Office1" #1: initiating Aggressive Mode 
112 "Office1" #1: STATE_AGGR_I1: initiate 
010 "Office1" #1: STATE_AGGR_I1: retransmission; will wait 0.5 seconds for response 
010 "Office1" #1: STATE_AGGR_I1: retransmission; will wait 1 seconds for response 
003 "Office1" #1: ignoring unknown Vendor ID payload [0048e2270bea8395ed778d343cc2a076] 
003 "Office1" #1: ignoring unknown Vendor ID payload [5cbeb399eb835a7d7a2eb495905db061] 
003 "Office1" #1: ignoring unknown Vendor ID payload [810fa565f8ab14369105d706fbd57279] 
002 "Office1" #1: Peer ID is ID_FQDN: '@Office' 
002 "Office1" #1: WARNING: connection Office1 PSK length of 13 bytes is too short for sha2_256 PRF in FIPS mode (16 bytes required) 
002 "Office1" #1: Peer ID is ID_FQDN: '@Office' 
004 "Office1" #1: STATE_AGGR_I2: sent AI2, ISAKMP SA established {auth=PRESHARED_KEY cipher=aes_256 integ=sha2_256 group=MODP2048} 
002 "Office1" #2: initiating Quick Mode PSK+ENCRYPT+TUNNEL+PFS+UP+AGGRESSIVE+IKEV1_ALLOW+IKEV2_ALLOW+SAREF_TRACK+IKE_FRAG_ALLOW+ESN_NO {using isakmp#1 msgid:f067a0d5 proposal=AES_CBC_256-HMAC_SHA2_256_128-MODP2048 pfsgroup=MODP2048} 
117 "Office1" #2: STATE_QUICK_I1: initiate 
010 "Office1" #2: STATE_QUICK_I1: retransmission; will wait 0.5 seconds for response 
002 "Office1" #2: prepare-client output: net.ipv4.conf.vti0.disable_policy = 1 
002 "Office1" #2: prepare-client output: net.ipv4.conf.vti0.rp_filter = 0 
002 "Office1" #2: prepare-client output: net.ipv4.conf.vti0.forwarding = 1 
002 "Office1" #2: route-client output: done ip route 
004 "Office1" #2: STATE_QUICK_I2: sent QI2, IPsec SA established tunnel mode {ESP/NAT=>0x7ab81f99 <0xa80c1c82 xfrm=AES_CBC_256-HMAC_SHA2_256_128 NATOA=none NATD=xx.yyy.zzz.vv:4500 DPD=passive} 

Mas não consigo tráfego pelo túnel. Não sei porque! Há algo mais a fazer? Criando uma rota talvez, mas como?

Se eu fizer um ping no 192.168.92.10, o tcpdump mostra:

13:45:31.577013 IP 192.168.92.234  > 192.168.92.10: ICMP echo request, id 4654, seq 1, length 64 

O

ip tunnel show oferece:

vti0: ip/ip remote xx.yyy.zzz.vv local 192.168.42.91 ttl inherit key 5
ip_vti0: ip/ip remote any local any ttl inherit nopmtudisc key 0

endereço IP show:

vti0@NONE: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1332 qdisc noqueue state UNKNOWN group default qlen 1000
link/ipip 192.168.42.91 peer xx.yyy.zzz.vv
inet 192.168.92.234/24 scope global vti0
   valid_lft forever preferred_lft forever

show de rotas ip:

default via 192.168.42.129 dev enp0s12u2 proto dhcp metric 100
xx.yyy.zzz.v dev vti0 scope link 
169.254.0.0/16 dev enp0s12u2 scope link metric 1000 
192.168.42.0/24 dev enp0s12u2 proto kernel scope link src 
192.168.42.91 metric 100 
192.168.92.0/24 dev vti0 proto kernel scope link src 192.168.92.234 

Parece que nenhum pacote está voltando. O que está errado - o que está faltando?