OpenVPN + OSPF Equal Cost Paths

  • We have a number of sites that we have interconnected with site to site openvpn links, and we're using FRR OSPF to optimize routing and provide failover routes when WAN links go down etc.

    It all works fine on the whole, but if two paths are of equal cost, the affected link fails. For example:

    N [130] area:
    via, ovpnc2
    via, ovpnc1

    In this case, the path cost via ovpnc2 and ovpnc1 are identical (130), and connectivity between the local LAN and is broken.

    Does anyone know what causes this, and how to fix it?

  • Rebel Alliance Developer Netgate

    Current releases do not support multi-path routing/ECMP, so I'm not sure what it might be trying to do there.

    Just yesterday we enabled RADIX_MPATH in snapshot kernels and multipath support in FRR, so you might give a 2.5.0 snapshot a try once that's built in.

  • Just saw this after posting my thread - missed it before. Find it here

    I have a similar problem, am not running OpenVPN though (IPSec).

    If you enable firewall logging or packet capture, you might be able to see if your reply traffic is taking the other way back - which doesn't work very well.

  • Rebel Alliance Developer Netgate

    If you change your state type to Sloppy on the rules it may help there, though you might need some additional floating rules. Similar to other asymmetric routing issues but not quite so bad since pfSense sees all packets, just not on the same interfaces.

  • Many thanks for the replies here. For now I've bodged things so that it's mathematically unlikely that two paths will end up with the same cost, but looking forward to trying out multipath support in FRR when it becomes more available / stable.

    mi8088 - I haven't actually taken a look at the packet captures yet, but yes, I imagine you're right that the return traffic is coming back via a different path.

  • @jimp
    I've been testing my setup in 2.5.0, but have the same issues still. Do I have to enable the multipath support somehow?

  • @gdi2k
    We deployed VTI+FRR (2.4.4p3) and that was a disaster. We're thinking about trying OpenVPN+FRR. Do you know if this issue is resolved in the newer (v0.6.3_1) versions of FRR?

Log in to reply