Old states being used after IPSEC comes up

[Konan]

I'm having an issue with routes via WAN interface being present after an IPSEC VPN is established with the remote IP in the policy.

That's a terrible explanation so I'll try and give the actual example.

Local subnet is 192.168.1.0/24
SIP phone is set with an account on 192.168.2.100
IPSEC VPN is down (WAN connectivity, maintainence etc)

Phones are still trying to make connections to 192.168.2.100:5600 (UDP) and follow the default route via WAN (and NAT)

IPSEC then comes up.

The state remains alive and is used until I manually kill it. The phone then begins to route via IPSEC

In other firewalls I'd usually create some kind of policy route that dictated the next hop destined for the remote subnet should always go via IPSEC but I'm not seeing a way to do that with gateway rules. I'm assuming there's no script on IPSEC establishment that kills states relating to the remote subnet.

[cmb]

The only way that should be possible for traffic matching the SPD is if it was initiated before IPsec was configured. Traffic matching the SPD will never leave WAN regardless of whether or not the VPN's up, it triggers it to try to connect and is dropped if it fails to connect. There's no way to kill states or policy route that traffic, as it's never been necessary.

I'm guessing that connection was established before you'd configured the VPN?

You can add floating rules, quick, direction out, on WAN that blocks traffic destined to 192.168.2.0/24. But with IPsec that should never be necessary.

[Konan]

Thanks for your reply.

I've observed this behaviour after a prolonged outage on the WAN of the remote site, no configuration changes were made to the VPN at any point. However, I think I need to take the time to try and recreate the circumstances as I observed this during a break-fix situation, so may have overlooked something in my efforts to get the affected systems up asap.

I will try to come back with more detail.

[cmb]

Hm, might be some edge case there where somehow the SPD isn't populated. If strongswan's running at all, it'll have that populated though. I can't think of any circumstance where that could occur. Definitely would be interested in steps to replicate if you come across something.

If IPsec were disabled for any period of time during troubleshooting, that could explain it.