WebRTC Error 1007 if accessing bbb through a fire wall

[Richard Rafalski]

Hello,

i followed this instructions
http://docs.bigbluebutton.org/1.0/10install.html#installing-bigbluebutton-1-0-beta
to install bbb in a local lan (192.168.2.0/24).

bbb is running in a virtual machine.

Everything went well. The WebRTC audio test that have been performed from a local computer (ip
192.168.2.2) succeeded also.

In a second step I used this instructions
http://docs.bigbluebutton.org/support/faq.html#can-i-provide-external-access-to-a-bigbluebutton-server-behind-my-firewall
to configure access from the internet.


The web interface of bbb was accessible from a remote machine but the WebRTC test failed.

The setup is
[remote machine] -> [reomte nat firewall] -> internet -> [lokal nat firewall] -> [bbb server]

All tests described in
http://docs.bigbluebutton.org/support/faq.html#can-i-provide-external-access-to-a-bigbluebutton-server-behind-my-firewal
have been successful.

tcpdump on the remote machine showed that the webbrowser sent udp packets to the internal address
(192.168.2.122) of the [bbb server] only. No packets have been sent to the external address of the
[lokal nat firewall].

Any hints how to solve this problems?

Thank you
Richard

[Chad Pilkey]

WebRTC generally doesn't like double NAT situations and they tend to be tricky to solve. Try these steps using whatever your public IP address is for the external IP address. I would suggest creating a backup of each of the FreeSWITCH files that you have to edit so that you can revert back if it doesn't work. Make sure to forward TCP ports 5060, 5066, 5070, 7443 (if https is setup) and UDP ports 16384 to 32768 from your firewall to your BBB server.

[Richard Rafalski]

Hi Chad,

adjusting the configuration exactly like you suggested do not change the situation. The webbrowser
on the remote machine still sends udp packets to the internal address 192.168.2.122.

Do you have a setup with to nat devices up and running?

Thank you
Richard

Am 20.10.2015 um 21:48 schrieb Chad Pilkey:
> WebRTC generally doesn't like double NAT situations and they tend to be tricky to solve. Try these

> steps <http://docs.bigbluebutton.org/install/install.html#audio-not-working> using whatever your

> public IP address is for the external IP address. I would suggest creating a backup of each of the
> FreeSWITCH files that you have to edit so that you can revert back if it doesn't work. Make sure to
> forward TCP ports 5060, 5066, 5070, 7443 (if https is setup) and UDP ports 16384 to 32768 from your
> firewall to your BBB server.
>
> On Tuesday, October 20, 2015 at 3:30:56 PM UTC-4, Richard Rafalski wrote:
>
> Hello,
>
> i followed this instructions
> http://docs.bigbluebutton.org/1.0/10install.html#installing-bigbluebutton-1-0-beta
> <http://docs.bigbluebutton.org/1.0/10install.html#installing-bigbluebutton-1-0-beta>

> to install bbb in a local lan (192.168.2.0/24 <http://192.168.2.0/24>).

>
> bbb is running in a virtual machine.
>
> Everything went well. The WebRTC audio test that have been performed from a local computer (ip
> 192.168.2.2) succeeded also.
>
> In a second step I used this instructions
> http://docs.bigbluebutton.org/support/faq.html#can-i-provide-external-access-to-a-bigbluebutton-server-behind-my-firewall
> <http://docs.bigbluebutton.org/support/faq.html#can-i-provide-external-access-to-a-bigbluebutton-server-behind-my-firewall>
>
> to configure access from the internet.
>
>
> The web interface of bbb was accessible from a remote machine but the WebRTC test failed.
>
> The setup is
> [remote machine] -> [reomte nat firewall] -> internet -> [lokal nat firewall] -> [bbb server]
>
> All tests described in
> http://docs.bigbluebutton.org/support/faq.html#can-i-provide-external-access-to-a-bigbluebutton-server-behind-my-firewal
> <http://docs.bigbluebutton.org/support/faq.html#can-i-provide-external-access-to-a-bigbluebutton-server-behind-my-firewal>
>
> have been successful.
>
> tcpdump on the remote machine showed that the webbrowser sent udp packets to the internal address
> (192.168.2.122) of the [bbb server] only. No packets have been sent to the external address of the
> [lokal nat firewall].
>
> Any hints how to solve this problems?
>
> Thank you
> Richard
>

> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> bigbluebutton-s...@googlegroups.com
> <mailto:bigbluebutton-s...@googlegroups.com>.
> To post to this group, send email to bigbluebu...@googlegroups.com
> <mailto:bigbluebu...@googlegroups.com>.
> Visit this group at http://groups.google.com/group/bigbluebutton-setup.
> For more options, visit https://groups.google.com/d/optout.

[Chad Pilkey]

I haven't tried it myself, but the instructions in our documentation are very close to the documentation on the official FreeSWITCH https://freeswitch.org/confluence/display/FREESWITCH/NAT+Traversal#NATTraversal-FreeSWITCHBehindNAT

> bigbluebutton-setup+unsub...@googlegroups.com
> <mailto:bigbluebutton-setup+unsub...@googlegroups.com>.

[Richard Rafalski]

I have checked the instructions on the freeswitch website you linked to. But this did not help
either. Maybe will find some time to go deeper into this topic in the future.

But one observation is interesting:

If i do destination nat on the client machine and replace the internal ip of the bbb server by the
external ip of the bbb server within outgoing ip packets everything seems to work fine.

That means for me, that there is no problem with fire wall etc. but the only thing that causes the
problem is the fact that the client is using the internal address of the bbb server instead the
external.

Is it possible to configure the client to use a certain server ip address?

Thank you
Richard

> > bigbluebutton-s...@googlegroups.com <javascript:>
> > <mailto:bigbluebutton-s...@googlegroups.com <javascript:>>.
> > To post to this group, send email to bigbluebu...@googlegroups.com <javascript:>
> > <mailto:bigbluebu...@googlegroups.com <javascript:>>.

> > Visit this group at http://groups.google.com/group/bigbluebutton-setup

> <http://groups.google.com/group/bigbluebutton-setup>.
> > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.

>
> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> bigbluebutton-s...@googlegroups.com
> <mailto:bigbluebutton-s...@googlegroups.com>.

[Chad Pilkey]

All the client knows is what IP address to use when setting up the websocket for initial communication (https://github.com/bigbluebutton/bigbluebutton/blob/master/bigbluebutton-client/resources/prod/lib/bbb_webrtc_bridge_sip.js#L233). Once the websocket has been set up SDPs are exchanged which contain the candidates that each side of the call are offering up. The reason your call doesn't work is because the server is offering up a candidate that uses a private IP. You can read through the browser console and you will see the unreachable private IP in the server's returned SDP. The "audio not working" steps that I linked to in my first reply should have changed the offered candidate to your firewall IP, but for some reason it did not.

You could potentially hack the SIP.js code to change every received candidate to whatever your firewall IP is, but I don't have any idea where in the code you would do that. https://github.com/bigbluebutton/bigbluebutton/blob/master/bigbluebutton-client/resources/prod/lib/sip.js

>     > bigbluebutton-setup+unsub...@googlegroups.com <javascript:>
>     > <mailto:bigbluebutton-setup+unsub...@googlegroups.com <javascript:>>.

>     > To post to this group, send email to bigbluebu...@googlegroups.com <javascript:>
>     > <mailto:bigbluebu...@googlegroups.com <javascript:>>.
>     > Visit this group at http://groups.google.com/group/bigbluebutton-setup
>     <http://groups.google.com/group/bigbluebutton-setup>.
>     > For more options, visit https://groups.google.com/d/optout <https://groups.google.com/d/optout>.
>
> --
> You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to

> bigbluebutton-setup+unsub...@googlegroups.com
> <mailto:bigbluebutton-setup+unsub...@googlegroups.com>.

[Andrey Bagrovsky]

Hello, Chad.

I have a few days thinking about this problem. I can not put a BBB-server before NAT, as did participants in other subjects.

Do I understand your answer to Richard? Do you think that the problem is sip.js? Or it may be the case in settings Freeswitch? I tried a lot of customization options, but so far has not solved the problem :(

понедельник, 26 октября 2015 г., 22:47:07 UTC+6 пользователь Chad Pilkey написал:

[Chad Pilkey]

If you want to use WebRTC, both side can't be behind NAT. If both sides are behind NAT the only way around it is to set up a TURN server and all of your media can be routed through there. There are special requirements for TURN servers though, such as it can't be behind NAT and it needs two IP addresses. It's not really a problem with FreeSWITCH or with sip.js it's just the nature of peer-to-peer communication and WebRTC.

The FreeSWITCH documentation suggested that there might be a way to change some settings to get it to work behind NAT, but in my opinion it is more trouble than it is worth. My two suggestions are either remove the NAT blockage or just turn off WebRTC use in your config.xml.