I also don’t think this is intentional and the state of the XFRM under the covers gets all wonky.
The reason I say this is because on R2 when I was setting it up, the xfrm0 interface came up just fine with my config without having to reboot while R1 the policy wouldn’t utilize the xfrm0 interface until I rebooted.
Tried looking in the debug logs, but tbh, I’m not really that experienced enough to understand what it’s trying to tell me.
Edit
Something’s I’ve learned on why I was having a hard time with the IPSEC config which may be useful when it comes to using IPSEC with an XFRM interface.
- If your responder (hub) is using a mode-config, you will need to set a manual policy with 0.0.0.0/0 as both the src/dst and not a template for both the responder and the initiator. The reason I found for this is when connecting, the responder will automatically create a policy from the template but will autofill the dst-address with the one in the mode-config
This will fail as both sides need to have the same policy, the initiator would manually have 0.0.0.0/0 for the src/dst and the responder would have a policy where 0.0.0.0/0 is the src but 192.168.10.2/24 for the dst-address (made up address but assume that is what was filled in for the mode-config address)
- Next, from what I was reading from other vendors, it’s mandatory to set 0.0.0.0/0 when using VTI, places like Cisco will ONLY let you use “ip any any” when configuring an VTI.
Reason for this is although you’re creating an xfrm interface and it’s route-based, it still uses the policy’s underneath which are just scoped to the interface. If you don’t have 0.0.0.0/0 set and only the virtual ip addresses of the initiator and responder, then any traffic coming in that doesn’t match those addresses will not be passed to the IPSEC encryption engine and will likely be dropped or sent to the default route.
Which is why it doesn’t make sense not use to 0.0.0.0/0 anyways as everything will be controlled by what you push through it with the routing table anyway.