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! _______________________________________________ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
