openbgpds not talking each other since 8.2-STABLE upgrade

J David j.david.lists at gmail.com
Thu Jan 5 22:08:39 UTC 2012


I am experiencing the same problem with bgpd and FreeBSD 8.2-STABLE as
described in this thread.  If I have correctly interpreted this
thread, it is currently not possible to have an OpenBGPd that speaks
TCP-MD5 to some peers, but not to others on FreeBSD.  Is that correct?

(It seems possible to bend this rule by tricking it to listen for the
non-MD5 connections and initiate the MD5 ones by using the hack/patch
posted here that turns off MD5 on the listening socket, but only
allowing connections to be initiated in one direction is out of spec
and a recipe for flaky connections.)

While I think I am following the discussion so far, and it has been
very informative, I am not sure where to go from here to actually
resolve this problem correctly.

I feel like if I had/understood the answer to Claudio's question:

> How does FreeBSD avoid the chicken and egg problem of accepting
> connections with MD5SIG?

I might feel more like I knew what to do next.  Although I think, for
me, the question generalizes to "How should one listen for client
connections on FreeBSD if some clients will use TCP_MD5SIG and some
will not?"  Sorry if that's a silly question; I have not been able to
dig up a lot of how-to programming information for IPSec on FreeBSD.
But the tcp(4) man page suggests that if you don't set a key on the
connection, "it will have an invalid digest option prepended."

I also found this on the tcp(4) man page:

"In the current release, only outgoing traffic is digested; digests on
incoming traffic are not verified."

Is this still true after the recent changes?  It doesn't *feel* true
based on these problems, but I haven't tested for it specifically.

Thanks!


More information about the freebsd-net mailing list