opnsense / opnsense/plugins

os-frr: OSPF MD5 fails after FRR 10.6.1 with ExtremeXOS — upstream fix is FRR #22744

Open
#5,652 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
PHP
Stars
1.2k
Forks
863
Avg merge
2d 6h
Merged PRs (30d)
10

Description

Important notices
Before you add a new report, we ask you kindly to acknowledge the following:

Describe the bug
Hello,

On 25.10.2_12, OSPFv2 with MD5 next to ExtremeXOS 31.7.1.4 was stable. After the upgrade to OPNsense Business 26.4.1p1_3 (os-frr + frr10), MD5 adjacencies no longer come up.

We switched the interface to another mode so routing works again.

26.4 ships FRR 10.6.1, that daemon requires a strictly increasing MD5 cryptographic sequence number (FRRouting/frr#21096). ExtremeXOS may reuse the same sequence for more than one packet in the same second, which RFC 2328 allows, so valid packets are dropped. In our network MD5 OSPF actually went down.

This is already fixed upstream as an interoperability switch (strict stays the default):

That pull request is not a ticket we opened. FRR 10.7.0 does not include the command yet (it landed after 10.7.0). Community 26.7.2 still has FRR 10.6.1 as well.

We believe this is mixed-vendor interoperability, and not a weaker MD5. The hash is still checked, only the sequence comparison matches RFC 2328.

To Reproduce

Steps to reproduce the behavior:

  1. Run OPNsense Business 26.4.1p1_3 with os-frr, OSPFv2 MD5 (message-digest) toward ExtremeXOS 31.7.1.4 (matching key ID and key).
  2. Confirm the same MD5 setup worked on 25.10.2_12.
  3. After the 26.4 upgrade, the OSPF neighbor does not stay up / does not reach Full.
  4. FRR logs a cryptographic sequence rejection, example: ospf_auth_check_md5_digest bad sequence N (expect > N).
  5. Change authentication method, the adjacency comes up again.

Expected behavior

MD5 to ExtremeXOS works again, as it did on 25.10.

Any of these would work for us:

  1. Patch on Business 26.4 — backport FRR #22744 onto the current frr10 package (10.6.1), plus a way in os-frr to persist no compatible rfc7474 (GUI option or documented manual snippet).
  2. Community package update (26.7.x) with that backport or a later FRR that already contains #22744, then the same on Business 26.4 when you consider is ok.
  3. Next FRR / OPNsense major — only if a 26.4 patch is not practical.
router ospf
 no compatible rfc7474

Screenshots

N/A. Happy to attach if it will be useful.

Relevant log files

Typical FRR warning (same class as FRR #21387):

ospf_auth_check_md5_digest bad sequence <N> (expect > <N>), Router-ID: <extreme-router-id>

We can provide the output of other commands if that would help.

Additional context

RFC 2328 Appendix D.4.3 (sender): sequence is non-decreasing; a clock-based sender may reuse one value in the same second.
https://datatracker.ietf.org/doc/html/rfc2328#page-232

RFC 2328 Appendix D.5.3 (receiver): discard only if received sequence is less than the last recorded value (equal is valid).
https://datatracker.ietf.org/doc/html/rfc2328#page-235

Mode Command Behavior
Hardened (default, current 26.4) compatible rfc7474 Sequence must strictly increase
Interoperability (RFC 2328) no compatible rfc7474 Equal sequence numbers are accepted

Thank you for looking at this.

Environment

OPNsense Business 26.4.1p1_3 (amd64), now 26.4.1p2
os-frr 1.53
frr10 10.6.1
Peer: ExtremeXOS 31.7.1.4, OSPFv2 MD5
Last known working: OPNsense Business 25.10.2_12
Hardware: DEC4280 (Deciso B V NetBoard-A30 x86 [64bit])

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by examining the os-frr and frr10 package entry points for FRR 10.6.1 and the router ospf configuration path. Compare the requested behavior with upstream FRR #22744 and the no compatible rfc7474 command. Done means the interoperability option is backported or available in the supported package and can be persisted for OSPFv2 MD5 configurations.

Written by the indexing model from the issue text.

Assessment

Domain
networking
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
48/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.