os-frr: No support for authentication in BGP

[Be-El]

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

[x] I have read the contributing guide lines at https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md

[x] I have searched the existing issues and I'm convinced that mine is new.

[x] When the request is meant for an existing plugin, I've added its name to the title.

Is your feature request related to a problem? Please describe.
For a sane production setup, BGP routing should be protected at least by a password.

Describe the solution you'd like
A field should be added to the neighbor table taht contains the MD5 password used to authenticate to the given neighbor. The fields content needs to be added as 'neighbor password ' to the configuration if set to a concrete value.
See also http://docs.frrouting.org/en/latest/bgp.html#clicmd-[no]neighborPEERpasswordPASSWORD

Describe alternatives you've considered
Running BGP without passwords, but I would consider this insecure and unsuited for production use.

[mimugmail]

I failed in my tests with just passwords, doesn't this require some kernel tweaks?

[mimugmail]

I played with this a bit, 2 problems

@fichtner for this I need TCP_SIGNATURE in kernel ( FRRouting/frr#1479 )
@AdSchellevis This feature needs to add keys via setkey ( FRRouting/frr#1479 (comment) ) and I'm not sure where this would fit best as already ipsec touches it.

[AdSchellevis]

@mimugmail I don't think we currently can distinct the different sa entries, in which case I expect the manual ones might be dropped by the ipsec module (haven't tested it).

https://github.com/opnsense/core/blob/87efd07831bc136416a5bd435e6bb67716c16ce7/src/etc/inc/plugins.inc.d/ipsec.inc#L674-L770

The current construction isn't great, but it's quite time consuming to workout better alternatives, which I'm currently not planning to invest (if I'm not mistaken, ideally the policies should be assigned after the tunnel comes up, for which we miss events. Last time I spend time on setkey, I also remember the documentation and examples weren't really helpful).

[mimugmail]

@AdSchellevis Users of BGP with IPsec in combination should be near zero as the encrypted traffic is already safe.
Would it be ok if I add a script and add a warning in the plugin? MD5 passwords in BGP are not common on my side and this about the 3rd or 4th request (incl. forum) so I'd like to work on it (if we also add the kernel option)

[AdSchellevis]

@mimugmail sure, I can live with that if it doesn't lead to weird race conditions (at a first glance this looks quite static). If we can exclude these entries easily, I don't even mind changing some of the ipsec code, but someone needs to test it and collect the different scenarios that do exist.

[rcmcdonald91]

I've got a provider that insists on password authentication for BGP. This would be nice to have.

[mimugmail]

@fichtner what so you think about adding signature support to kernel?

[fichtner]

Well, does it work nowadays?

[mimugmail]

In the first step we need to add kernel support in general as this is no real authentication inside BGP protocol, rather on the TCP layer. In a second step we have to add/manipulate for each neighbor the SPD database like with ipsec, but I can't test second when kernel features are missing.

[mimugmail]

@fichtner any news about MD5 Kernel support?

[rcmcdonald91]

Well with the WireGuard fiasco over at pfSense, I’m really eager to move over here. This is the most significant barrier to that means. Any update?

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[mimugmail]

Please reopen and assign me .. some day I can motivate @fichtner to add this option :)
Steter Tropfen hölt den Stein ...

[fichtner]

@mimugmail I went back in tools git but I never found a kernel that didn't have TCP_SIGNATURE unset...

https://github.com/opnsense/tools/blob/ae1fabd98527460cddac3c74335259a3500fc13a/config/21.1/SMP#L18

What am I missing?

[mimugmail]

Hm, I was under the impression it's not in yet, maybe I looked at the wrong files or we crosstalked in IRC.
Ok, I'll have a go the next week working with the spd :)

[mfld-pub]

Well with the WireGuard fiasco over at pfSense, I’m really eager to move over here. This is the most significant barrier to that means. Any update?

+1. Showstopper for us right now.

Upstream demands that we set a neighbor password and our environment demands that we set

ebgp-multihop 2

as well as

no bgp network import-check

once FRR 7.5 is introduced. Right now OpnSense is on 7.4 so this isn't an issue yet but soon will be.

No doubt it is impossible to expose all possible scenarios in the GUI without making it look ridiculous - FRR is vast.

But Perhaps as a compromise for now expose a RAW CONFIG in the GUI where one can override the settings. That way we can use the GUI to get most of the way there and then add the 1 or 2 extra lines of needed tweaks to the resulting config file. This could come in especially handy when FRR 7.5 is added to OpnSense as it has new RPKI capabilities that are becoming best-practice right now and one needs a way to enable that down the track, too.

[fichtner]

But Perhaps as a compromise for now expose a RAW CONFIG in the GUI where one can override the settings.

No chance. You can use FRR manually as a FreeBSD port/package if the plugin cannot cover your use cases.

[thexa4]

I'd also like to migrate away from pfSense and have the same requirement from my upstream provider to use MD5 authentication and multihop 2.

Is there any way I can help to fix this issue?

[mfld-pub]

The required module seems to be present and loaded in vanilla OPNsense 21.1.5:

root@opnsense-github-issue-1972:~ # kldload tcpmd5
kldload: can't load tcpmd5: module already loaded or in kernel

I will try install the FRR FreeBSD package, make it work and then work my way from there. I am guessing the MD5 TCP secret has to go into ipsec.conf as it would on FreeBSD-12.2

add [neighbor ip] [router ip] tcp 0x1000 -A tcp-md5 "[bgp session secret]";

I gather the challenge here lies in not making os-frr overwrite or break actual IPSEC secrets?

[mimugmail]

https://bird.network.cz/pipermail/bird-users/2018-March/012094.html

In a file somewhere:

# /etc/setkey.conf
flush;		# useful when running mutations manually
spdflush;	# useful when running mutations manually
add -4 12.34.56.6 12.34.56.7 tcp 0x1000 -A tcp-md5 "teNp8XUrZtNteNjbep68jXgUGroZtUN";
add -4 12.34.56.7 12.34.56.6 tcp 0x1000 -A tcp-md5 "teNp8XUrZtNteNjbep68jXgUGroZtUN";

Then:
setkey -v -f /etc/setkey.conf

Seems to work, but I didn't check in live system.
@AdSchellevis If I add this to FRR plugin it might break NAT inside IPsec since all SPD are flushed.
But I think it's highly unsual to use BGP inside IPsec and also natting stuff. What do you think?

[AdSchellevis]

@mimugmail I'm not a huge fan to be honest, my experience so far is that some day someone opens ticket why this can't be combined and starts rambling everything is stupid. If it's the only way, so be it, but if we can engineer something smarter that would be my preference.

[mimugmail]

I'm not sure about the glue between spd in legacy code and frr mvc .. but I'll have a look :)

[mmack]

If you guys need someone for testing ping me... I have the same problem on vultr.com

[mimugmail]

Ok, I successfully tested the approach above by hand, I try to get a draft next week. :)

[mmack]

@mimugmail any progress so far? Can we test it?

[mimugmail]

I try to start this evening, thx for the reminder :)

[mmack]

@mimugmail Can i buy you a coffee? 😄

[mimugmail]

Sure :)

#2645

[OPNsense-bot]

This issue has been automatically timed-out (after 180 days of inactivity).

For more information about the policies for this repository,
please read https://github.com/opnsense/plugins/blob/master/CONTRIBUTING.md for further details.

If someone wants to step up and work on this issue,
just let us know, so we can reopen the issue and assign an owner to it.

[mimugmail]

This is already implemented, so help wanted is not correct :)

[Chikito7]

Hi Guys,

it seems it doesn't work using the below:

FRRouting 7.5.1 (OPNsense.localdomain).
OPNsense 22.7.10_2-amd64
FreeBSD 13.1-RELEASE-p5

Do you think the fix will come in the plugin itself with upcoming release ?

[mfld-pub]

It never worked for us. Session with IPv6 and bidirectional setkey MD5 secret just stays "Active".

Logs show an error that may or may not be relevant 2023-01-19T02:46:06 | Error | bgpd | [EC 100663299] buffer_flush_available: write error on fd 2: Bad file descriptor

Just tried again from scratch as the last time I tried was ~12 months ago. Now on

OPNsense 22.7.11-amd64
FreeBSD 13.1-RELEASE-p5
os-frr-1.31

[mimugmail]

Can you add a screenshot of neighbor config?

[mfld-pub]

Can you add a screenshot of neighbor config?

Sure thing!

The MD5 secret has no special characters and is of this sort of format: uzyV8qHiVmXlT2B2

The prefix lists allow one prefix to be announced and default route to be received.

Sanitized running config:

Building configuration...

Current configuration:
!
frr version 7.5.1
frr defaults traditional
hostname testbox.opnsense.rocks
log syslog
!
router bgp 64500
 bgp router-id 22.120.12.93
 no bgp ebgp-requires-policy
 no bgp default ipv4-unicast
 bgp graceful-restart
 no bgp network import-check
 neighbor 2001:19f0:ffff::1 remote-as 64515
 neighbor 2001:19f0:ffff::1 password uzyV8qHiVmXlT2B2
 neighbor 2001:19f0:ffff::1 ebgp-multihop 255
 neighbor 2001:19f0:ffff::1 disable-connected-check
 !
 address-family ipv6 unicast
  network 2001:db8:1014::/48
  neighbor 2001:19f0:ffff::1 activate
  neighbor 2001:19f0:ffff::1 prefix-list default-in-v6 in
  neighbor 2001:19f0:ffff::1 prefix-list default-out-v6 out
 exit-address-family
!
ipv6 prefix-list default-in-v6 seq 100 permit ::/0
ipv6 prefix-list default-out-v6 seq 100 permit 2001:db8:1014::/48
!
line vty
!
end

[mimugmail]

You need to fill local Initiator IP to get this working. Maybe something for the docs

[mfld-pub]

You need to fill local Initiator IP to get this working. Maybe something for the docs

Oh, it is not resolving from Update-Source Interface ? I will test again.

Should this work IPv6 - only ?

[mimugmail]

It is used for setkey parameters

https://github.com/opnsense/plugins/pull/2800/files

[Chikito7]

Cool - will test it tomorrow.

Thanks

[Chikito7]

Tested and confirmed - it is working .

Thanks everyone !

[joachimtingvold]

Seems like this implementation only works for IPv4 BGP peers?

[mfld-pub]

This has been my experience too. Cannot turn up a session with an IPv6 neighbor.

[mimugmail]

Can you post the contents of the files in the PR above? Dont see a reason why it shouldnt work with v6

[joachimtingvold]

Can you post the contents of the files in the PR above? Dont see a reason why it shouldnt work with v6

Line 63 + 65 in net/frr/src/opnsense/scripts/frr/register_sas only adds/removes setkey stuff with the -4 parameter (which I assume limits it to IPv4, and thus IPv6 neighbors needs the -6 parameter).

Seems to be described in the manpage for setkey as well;

-4 and -6 restrict results into IPv4/v6 addresses only, respectively.

[joachimtingvold]

I see now that the contents of the PR above since has been updated via PR #3345 to allow for IPv6 peers. I can confirm that my OPNsense version is 23.1.11, which has #3345 incorporated. However, I cannot get IPv6 neighbors to work with MD5 passwords.