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