freeswitch configuration

1,323 views
Skip to first unread message

Brent W. Baccala

unread,
Oct 8, 2020, 6:30:38 PM10/8/20
to BigBlueButton-dev
Hi -

I've started using a modified freeswitch configuration pretty regularly, and we might want to make this change to the distributed system.

(TL;DR - I'd make a pull request, but I don't know where the source to the nginx configuration files are tracked)

The problem is that if the client and the server are both behind NAT gateways and their private IP address ranges overlap, then the server will try to use the client's private address, and that obviously won't work.

The problem can be traced to this portion of the Freeswitch external.xml file:

    <!-- Added for Microsoft Edge browser -->
    <param name="apply-candidate-acl" value="localnet.auto"/>
    <param name="apply-candidate-acl" value="wan_v4.auto"/>
    <param name="apply-candidate-acl" value="rfc1918.auto"/>
    <param name="apply-candidate-acl" value="any_v4.auto"/>

It's a prioritized list that tells Freeswitch how to pick one IP address out of a list of candidates that the client provided.  "localnet.auto" is generated automatically by Freeswitch and matches the local (private) subnet.  You can observe this by looking for lines like this in the Freeswitch log file (initial part of line deleted for clarity):

Created ip list localnet.auto default (deny)
Adding 192.168.1.86/255.255.255.0 (allow) to list localnet.auto

In the case, the server's address is 192.168.1.86, and the problem arises if the client has a private address in the 192.168.1.0/24 block, which will be selected because localnet.auto is first on the list.

What I've started doing is using the nginx geo module to match the IP address that the client is connecting from, and handling local (private) IP addresses separately:

geo $autonet {
  default 0;
}

Based on the value of $autonet, I then proxy_pass to either port 7443 or 7445, where I've got a another SIP profile listening with the localnet.auto line commented out.

It seems to have solved the problem.  Connections from outside the server's private address space always use the wan_v4.auto line, as they should.

I'd submit it as a pull request, but I don't know where the nginx configuration is maintained.  I don't see it in the main github repository.  Anybody know where it is?

    agape
    brent



Fred Dixon

unread,
Oct 8, 2020, 7:29:07 PM10/8/20
to BigBlueButton-dev
Hi Brent,

Thanks for sharing this -- I'm the maintainer of the packaging for BigBlueButton and, right now, it's an internal set of build scripts that have evolved over the years.  

We've not made it public in part because of the lack of proper documentation and to reduce our overall support effort (it's enough for us to try and support BigBlueButton itself).

I need to get the FreeSWITCH configuration files into the repo and modify the build scripts to pull from there.  The build system has been working well for a few years, and as soon as Covid-19 hit, our focus became full-on improving 2.2.

I'm going to review your changes again and do some testing internally, then see about getting them into the build proper -- or at least into the documentation.

Regards,... Fred



--
You received this message because you are subscribed to the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/56a8fcfb-70cf-4a7d-9834-387cf547ba07n%40googlegroups.com.


--
BigBlueButton Developer

Like BigBlueButton?  Tweet us at @bigbluebutton

Devrim Seral

unread,
Oct 11, 2020, 3:53:29 AM10/11/20
to BigBlueButton-dev
Dear Brent, 
This is very nice solution could you please share  nginx  config as well ? 
Because we have same problem here especially in local network if we have another machine behind NAT ( WiFi Nat Router) 
 Devrim

Brent W. Baccala

unread,
Oct 11, 2020, 3:57:43 PM10/11/20
to BigBlueButton-dev
Devrim -

This is what I've got.  I added the following lines to the beginning of /etc/nginx/site-available/bigbluebutton:

geo $autonet {
  default 0;
}

Then, I use the following /etc/bigbluebutton/sip.nginx:

location /ws {
        if ($autonet) {
                proxy_pass https://192.168.1.86:7445;
        }
        if ($autonet != 1) {
                proxy_pass https://100.36.123.208:7443;
        }
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "Upgrade";
        proxy_read_timeout 6h;
        proxy_send_timeout 6h;
        client_body_timeout 6h;
        send_timeout 6h;

auth_request /bigbluebutton/connection/checkAuthorization;
auth_request_set $auth_status $upstream_status;
}

The server's public IP address is 100.36.123.208, which is also configured on a loopback interface.  I think it's important that Freeswitch receive the private connections on the private address and the public connections on the public address, but I'm not 100% sure of that.

Finally, I copied /opt/freeswitch/conf/sip_profiles/external.xml to /opt/freeswitch/conf/sip_profiles/internal.xml and made the following changes: (there was already an internal.xml that I don't think we use, so I overwrote it)

1c1
< <profile name="external">
---
> <profile name="internal">
3c3
<   <!-- This profile is only for outbound registrations to providers -->
---
>   <!-- This profile is for inbound Big Blue Button connections on the local private LAN -->
28c28
<     <param name="sip-port" value="$${external_sip_port}"/>
---
>     <param name="sip-port" value="5062"/>
44c44
<     <!-- <param name="apply-candidate-acl" value="localnet.auto"/> -->
---
>     <param name="apply-candidate-acl" value="localnet.auto"/>
92c92,93
<     <param name="tls-sip-port" value="$${external_tls_port}"/>
---
>     <!-- but it's disabled by external_ssl_enable -->
>     <param name="tls-sip-port" value="5083"/>
108,109c109,110
<     <param name="ws-binding"  value=":5066"/>
<     <param name="wss-binding"  value="100.36.123.208:7443"/>
---
>     <param name="ws-binding"  value=":5068"/>
>     <param name="wss-binding"  value="192.168.1.86:7445"/>

In summary:
  1. change the profile name from "external" to "internal"
  2. change all four TCP port numbers (5060 -> 5062, 5081 -> 5083, 5066 -> 5068, 7443 -> 7445)
  3. comment out the apply-candidate-acl localnet.auto in external.xml (all the other changes are to internal.xml)
Now any internal connections go to port 7445 and match localnet.auto, while external connections go to port 7443 and never match localnet.auto.

This works for my network.  For something that works in the general case, we should probably match any private IP address, using something like this:

geo $rfc1918 {
  10.0.0.0/8            1;
  172.16.0.0/12         1;
  192.168.0.0/16        1;
  default               0;
}

Also, for internal connections, we should probably match any private address, not just the local subnet, so that would require using rfc1918.auto instead of localnet.auto.  So, I'm thinking that the external SIP configuration should look like this:

    <param name="apply-candidate-acl" value="wan_v4.auto"/>
    <param name="apply-candidate-acl" value="any_v4.auto"/>

and the internal SIP configuration should look like this:

    <param name="apply-candidate-acl" value="rfc1918.auto"/>
    <param name="apply-candidate-acl" value="any_v4.auto"/>

Finally, there's a known problem with wan_v4.auto - it matches carrier-grade NAT addresses, which is an additional NAT block (100.64.0.0/10; RFC 6598) used by cell phone carriers.  We don't want to use a cell phone's carrier-grade NAT address (just like we don't want to use any NAT address), so probably we want something like this for our external SIP configuration:

    <param name="apply-candidate-acl" value="wan_v4_without_cgnat.auto"/>
    <param name="apply-candidate-acl" value="any_v4.auto"/>

and then add the following to /opt/freeswitch/conf/autoload_configs/acl.conf.xml:

    <list name="wan_v4_without_cgnat" default="allow">
      <node type="deny" cidr="0.0.0.0/8"/>
      <node type="deny" cidr="10.0.0.0/8"/>
      <node type="deny" cidr="172.16.0.0/12"/>
      <node type="deny" cidr="192.168.0.0/16"/>
      <node type="deny" cidr="169.254.0.0/16"/>
      <node type="deny" cidr="100.64.0.0/10"/>
      <node type="deny" cidr="::/0"/>
    </list>

I know that's a lot of information, but I think it pretty much covers everything I've learned so far about how to configure Freeswitch to handle the current state of IPv4 addressing.

    agape
    brent

Devrim Seral

unread,
Oct 11, 2020, 4:09:08 PM10/11/20
to bigblueb...@googlegroups.com
Thank you Brent.. 
This is good information
Devrim

--
You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-dev/YEQJDxT2Mbk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to bigbluebutton-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-dev/840526ca-ab7e-4926-a1bc-57ebef665e7dn%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages