Enrutamiento de túnel Strongswan ipv6

Estoy tratando de resolver un problema extraño en el enrutamiento. Tengo mi enrutador configurado (Turris, ejecutando OpenWRT personalizado), con conexión IPv6 de tunelización Strongswan. Esto funciona bien para el enrutador en sí, ya que su conectividad ipv6 funciona bien (a través del túnel, mi proveedor no ofrece ipv6 nativo).

TL; DR: las rutas no se eligen como las esperaría, ya que la más genérica, :: / 0 parece ser siempre la preferida, aunque existe una coincidencia / 64

Pero cuando intenté extender esto a mi red doméstica, me topé con un problema y no puedo encontrar una causa.

Aunque el ipsec funciona, obtengo una interfaz ipsec0 y estas rutas:

Kernel IPv6 routing table
Destination                                 Next Hop                                Flags Metric Ref    Use Iface
::/0                                        ::                                      U     1024   0        2 ipsec0  
2a01:490:19:42::/64                         ::                                      U     1024   0        0 br-lan  

Aquí, 2a01: 490: 19: 42 :: / 64 es un rango que dediqué para mi red local, 2a01: 490: 19: 42 :: 1 es la dirección IP del enrutador en esa red.

Aquí hay algunas observaciones:

1) Cuando hago ping 2a01: 490: 19: 42 :: 1 desde una computadora en mi red local, el enrutador responde, pero envía la respuesta a la interfaz ipsec0. No tengo ni idea de porqué. ¿No debería favorecerse el prefijo más específico, 2a01: 490: 19: 42 :: / 64, en br-lan? Parece elegir correctamente la dirección IP de origen 2a01: 490: 19: 42 :: 1.

2) Lo mismo sucede cuando intento enviar un paquete desde mi red local a otro sitio, por ejemplo, ping6 stackexchange.com. Los paquetes llegan al enrutador, se reenvían, el servidor envía una respuesta, el enrutador lo recibe ... y lo envía de nuevo a la interfaz ipsec0.

3) No hay políticas xfrm. ip xfrm polno devuelve nada Pero Strongswan se está ejecutando y tenía la impresión de que Strongswan siempre crea algunas políticas. En mi configuración anterior, tuve que agregar algunos para permitir pasar paquetes al túnel, pero estoy un poco confundido acerca de que la lista de políticas esté vacía.

Muy bien, entonces, ¿qué pasa? ¿Por qué se prefiere la ruta más genérica, :: / 0, para mis paquetes ipv6?

¡Gracias!

El problema era que ipsec insertó sus reglas en una tabla de enrutamiento diferente (tabla 220) y creó una política para dirigir el tráfico allí:

root@turris:/etc/config# ip rule list
0:  from all lookup local 
220:    from all lookup 220 
32766:  from all lookup main 
32767:  from all lookup default 

Pero la tabla 220solo contenía la ruta predeterminada hacia el túnel ipsec, y no la red local:

root@turris:/etc/config# ip -6 r show table 220
default dev ipsec0  proto static  src 2a01:490:19:42::1  metric 1024 

Lo que inevitablemente provocó que todos los paquetes fueran enviados al túnel.

La red para el enrutador en sí funcionó solo porque fueron aceptados y no enrutados.

Arreglé esto instruyendo a strongswan para que inserte reglas de enrutamiento en la tabla principal, estableciendo charon.routing_table = 254(el id de main, como se ve en /etc/iproute2/rt_tables). Mi strongswan.confahora se ve así:

charon {
#       load_modular = yes
        plugins {
                include strongswan.d/charon/*.conf
        }
        routing_table = 254 # main
}