bigbluebutton / bbb-install

BASH script to install BigBlueButton in 30 minutes.
GNU Lesser General Public License v3.0
618 stars 538 forks source link

bbb-install on 2.6 does not configure haproxy to listen on ipv6 #665

Closed myOmikron closed 11 months ago

myOmikron commented 1 year ago

The /etc/haproxy/haproxy.cfg looks the following after upgrading from bbb 2.5:

frontend nginx_or_turn
  bind *:443 ssl crt /etc/haproxy/certbundle.pem ssl-min-ver TLSv1.2 alpn h2,http/1.1,stun.turn
  mode tcp
  option tcplog
  tcp-request content capture req.payload(0,1) len 1
  log-format "%ci:%cp [%t] %ft %b/%s %Tw/%Tc/%Tt %B %ts %ac/%fc/%bc/%sc/%rc %sq/%bq captured_user:%{+X}[capture.req.hdr(0)]"
  tcp-request inspect-delay 30s
  # We terminate SSL on haproxy. HTTP2 is a binary protocol. haproxy has to
  # decide which protocol is spoken. This is negotiated by ALPN.
  #
  # Depending on the ALPN value traffic is redirected to either port 82 (HTTP2,
  # ALPN value h2) or 81 (HTTP 1.0 or HTTP 1.1, ALPN value http/1.1 or no value)
  # If no ALPN value is set, the first byte is inspected and depending on the
  # value traffic is sent to either port 81 or coturn.
  use_backend nginx-http2 if { ssl_fc_alpn h2 }
  use_backend nginx if { ssl_fc_alpn http/1.1 }
  use_backend turn if { ssl_fc_alpn stun.turn }
  use_backend %[capture.req.hdr(0),map_str(/etc/haproxy/protocolmap,turn)]
  default_backend turn

Haproxy starts as expected on 0.0.0.0:443, but not on [::]:443.

After changing the bind part to:

  bind *:443,:::443 ssl crt /etc/haproxy/certbundle.pem ssl-min-ver TLSv1.2 alpn h2,http/1.1,stun.turn

and restarting haproxy.service, everything works as expected

ffdixon commented 1 year ago

Thanks for pointing this out -- it looks like a quick fix. We'll take a closer look.

schrd commented 1 year ago

bbb-install does not care about IPv6 if I understand that correctly. Adding the listen statement to haproxy should work, however you should investigate the behaviour of freeswitch if you enabled IPv6. If you do not use the fullaudio bridge, freeswitch expects the RTP traffic on the same protocol family as the sipjs websocket connection. So in this case turn servers also should be running a dual stack setup otherwise clients who need a TURN server might not be able to establish a connection if the clients connect using IPv6 and the TURN server only offers IPv4 candidates.

Daniel-at-git commented 1 year ago

I have stumbled across the same problem.

I modified haproxy.cfg and it's working with a ipv6 turn (on the same system (thanks to haproxy)).

Can somebody modify the install script for all other bbb users? https://github.com/bigbluebutton/bbb-install/blob/master/bbb-install-2.6.sh#L787

We have a lot of dual stack ligth customers. So ipv6 is much more stable.

BTW: test. and demo.bigbluebutton.org are not available via IPv6

Thanks!

ffdixon commented 1 year ago

@Daniel-at-git, are you able to test @schrd's comment to confirm that a TURN candidate on IPV6 for FreeSWITCH is able to connect when the websocket connection returns an iPV4 address (without using fullaudio setup)?

Daniel-at-git commented 1 year ago

@ffdixon Let's say it this way. I blocked all ports except 53,80 and 443 on my client and I have audio connection.

It tried to take a look to chrome developer tools. I can see the websocket but it didn't show any IP-Adresse. If I go to chrome://webrtc-internals/ I see an ipv4 address (starting with 78.46.). Screenshot_20230704_123752

I hope this answers you question.

KnudH commented 1 year ago

Still not fixed in 2.7... this costs me hours, because I though that I did something wrong, all the time. This should have a high priority I think.

myOmikron commented 11 months ago

@kepstin as #674 has made a PR with my proposed changes, can we close this issue?

ffdixon commented 11 months ago

Thanks @myOmikron for the merged pull request. Closing this issue.