MD5 auth-password not negotiating

[richard-chivers]

Hi,

We are having an issue where we can't seem to establish a BGP session with a multi-hop neighbor.

The neighbor is a mainstream T1 ISP with hundreds of active working configurations.

We have a working configuration with this bgp peer, using openbsd.

This worked previously when we were on an older version of Ubuntu, but we cannot get it to work again since the upgrade.

If we remove the password requirement, the connection comes up immediately.

Running a TCP dump we see x.x.x.x.23932 > x.x.x.x: Flags [S], cksum 0x92cf (correct), seq 281719169, win 16384, options [mss 4386,wscale 0,nop,md5 shared secret not supplied with -M, can't check - db77b52562c1345cad6a9367be3830f8,eol], length 0

At the other end, they are seeing UTC: tcp[463]: %IP-TCP-3-BADAUTH : Invalid MD5 digest from x.x.x.x:xx to x.x.x.x:179 for vrf:default

We are running behind nat, and we have tcpdumped at the firewall to show our outgoing nat is correct.

Is it possible that the md5 hash uses the local IP or similar to hash the password?

We have always run in this way, the only change is the OS upgrade, and I guess with that a gobgp upgrade too.

Also, we have checked: CONFIG_TCP_MD5SIG=y

Any help appreciated.

[brevius]

Hi,
Similar issue observed on Ubuntu 24 (3.23.0-1ubuntu0.2) and multihop sessions. The system is also behind NAT.
Directly connected systems (no NAT/multihop) are working correctly.

[richard-chivers]

We ended up having to publicly address the boxes to resolve this, and then it worked straight away with the same config.

[fujita]

I don't think that TCP MD5 mechanism works with NAT.

[richard-chivers]

It certainly used to, as we had multiple sessions that ran for years using it.

Very strange.

[fujita]

Hmm, the calculation of MD5 authentication includes the TCP pseudo-header, which contains the source IP address and destination IP address, right?