I would like to understand if this is expected behavior or is considered a bug.
I have an IPSEC tunnel setup on VyOS 1.1.7 with the tunnel terminating on Endpoint A. Both Phase 1 and Phase 2 are up. With that same VyOS router, I have a BGP peer with Endpoint B and it’s advertising the remote prefix of the tunnel (2.2.2.2/32).
The issue I am seeing comes into play when the tunnel’s remote prefix is added to the VyOS route table and I bring down the tunnel (Phase 1 is down). When the tunnel is configured using selectors, a kernel route is added to the routing table, for the remote prefix, on the VyOS router. When you bring down the tunnel, the kernel route does not get marked inactive or disappear from the routing table, which means the VyOS router will continue advertising 2.2.2.2/32 to Endpoint B. This basically creates a blackhole until the tunnel is up. I would expect the appropriate action would be the VyOS router would mark it inactive since the tunnel is down. I tested this same setup using a VTI and a static route and the VyOS router properly marked the static route as inactive and stopped advertising to Endpoint B. Using VTIs worked, however not all of our VPN endpoints will support Proxy IDs of 0.0.0.0/0.
VyOS Router Config Snippet
set vpn ipsec site-to-site peer x.x.x.x authentication mode pre-shared-secret
set vpn ipsec site-to-site peer x.x.x.x authentication pre-shared-secret xxx
set vpn ipsec site-to-site peer x.x.x.x authentication id y.y.y.y
set vpn ipsec site-to-site peer x.x.x.x ike-group xxx
set vpn ipsec site-to-site peer x.x.x.x default-esp-group yyy
set vpn ipsec site-to-site peer x.x.x.x local-address xxx
Using Proxy IDs. Creates a kernel route, when tunnel goes down kernel route stays and continues to advertise out BGP
set vpn ipsec site-to-site peer x.x.x.x tunnel 0 local prefix 1.1.1.1/32
set vpn ipsec site-to-site peer x.x.x.x tunnel 0 remote prefix 2.2.2.2/32
Let me know your thoughts.