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

[myOmikron]

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]

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

[schrd]

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]

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]

@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]

@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.).

I hope this answers you question.

[KnudH]

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]

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

[ffdixon]

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