VoIP behind NethServer

This is the model of nethserver, if you dont update this file, and alter config with interface of nethserver, his alter the original file.

1 Like

https://wiki.freeswitch.org/wiki/ALG

That makes sense. Itā€™s the template file location that the nethserver interface is based on and then writes to the config files from those. Thatā€™s good to know! Thanks!

Iā€™ve confirmed that this works for mine too. So should we submit a feature request to expose this as a check-box option in the web interface?

all calls are made without problems?
so workaroud is :

  1. mkdir -p /etc/e-smith/templates-custom/etc/shorewall/shorewall.conf
  2. cp /etc/e-smith/templates/etc/shorewall/shorewall.conf/60options
    /etc/e-smith/templates-custom/etc/shorewall/shorewall.conf/60options
  3. sed -i -e ā€˜s/DONT_LOAD=/DONT_LOAD=nf_nat_sip/gā€™ /etc/e-smith/templates-custom/etc/shorewall/shorewall.conf/60options
  4. signal-event firewall-adjust
2 Likes

Now youā€™re just showing off! :wink:

I ran out of time and had to go pick up my daughter, but I placed several incoming and outgoing calls and they all worked. Iā€™ll do more testing tomorrow morning.

Confirmed. All calls are working. I made at least a dozen test calls this morning.

Is there a possibility of this being added to the GUI?

Afaik we already know an issue such this. @mrchiao @filippo_carletti am I wrong?

1 Like

Bump. Is this going to be added as a check-box to disable/enable this shorewall module?

This module is using while you configure grant bandwidth for SIP traffic. So maybe it its better to configure rather disabling module.

and my workaround VoIP behind NethServer works

Workarounds are nice and all, but at the end of the day, wouldnā€™t it be better to improve NethServer and have something thatā€™s easier to use?

sureā€¦

NS is open source and you and your code are welcome :slight_smile:

@Adam I think we need to be sure that itā€™s not a bug in the nf_nat_sip kernel module before disabling it entirely.

Iā€™ll try to understand the problem next week, but if someone has more information about sip problems, please share them.
Thank you.

1 Like

Haha! Good answer! I used to program a bit around 15 years ago. As much as Iā€™d love to contribute in that area, all of that knowledge has since faded. So for now, I have the resources to do some solid testing and provide my results.

Thank you, Filippo. Please let me know if there are any specific logs or other information I can provide to help.

I did see a lot of information saying that the shorewall sip ALG modules are known to cause issues and itā€™s common practice to disable them if the PBX youā€™re using has settings for NAT. It makes sense to me since you donā€™t want the router changing packet headers when the PBX is already compensating for NAT.

Some links to those info would be perfect. Thanks.

1 Like

This is probably the most valid one to mention since itā€™s in the shorewall FAQ:
http://shorewall.net/FAQ.htm

Thank you @Adam.

I still canā€™t understand the source of the problem, though.
I read some docs, see these:


http://www.asteriskguru.com/tutorials/sip_nat_oneway_or_no_audio_asterisk.html

Do you think weā€™ll be safe if we modify NethServer to follow shorewall faq #77? Or we need an option to enable the faq only in case of problems?

If a PBX doesnā€™t have the ability to change packet headers to ā€˜hideā€™ NAT, it may be required to have the sip helpers enabled. So the preferred solution would be to have the option to enable/disable them as needed.

In my experience, where ALG has caused a problem with RTP traffic, this was the cause:

(quoted from the link you mentioned)

Most of you will know that NAT changes your private IP address to the
public IP address but not everyone knows that it ALSO changes the source
port. Using our examples above switch A uses IP 192.168.1.8 and 65875
but when this comes out the other side of the NAT it may be seen as
87.45.78.65 and port 87563. Simply put a STUN server detects this and
sends this information back to the switch so it can amend the SIP
packets accordingly.

One way audio was caused by expecting to receive data back on one port, but the port was changed by the router, and therefore the return data was dropped.

@Adam I suppose your PBX has NAT traversal but it could be enabled though console or somth like this. FreePBX and Elastix has NAT feature, STUN does not help coz STUN only informs about NAT