Network:Firewall:Configuration: Difference between revisions
From VTX Public Wiki
(Test Create page) |
(→Phone / VPBX / Connect / Firewall rules: Remove NB) |
||
(13 intermediate revisions by 4 users not shown) | |||
Line 1: | Line 1: | ||
'''The purpose of this page is to help partners and customer ITs to setup their firewall without having to guess for our Telephony Platform Access Lists.''' |
|||
'''A Copy of this page is available at https://wiki.vtx.ch/wiki/Network:Firewall:Configuration''' |
|||
{{Blackboxwarning|Please make sure your firewall is running the last stable version of his firmware and is not End Of Life or End Of Support because we coped with many bugs on Zyxel / Sophos / Sonicwall / ... firewalls running old versions}} |
{{Blackboxwarning|Please make sure your firewall is running the last stable version of his firmware and is not End Of Life or End Of Support because we coped with many bugs on Zyxel / Sophos / Sonicwall / ... firewalls running old versions}} |
||
{{Warning|SIP ALG: Because many implementations of SIP ALG are not working correctly (bug or incompatibility with some phones), we have configured the VoIP platform to handle NAT all the time. SO PLEASE DO NOT USE "SIP ALG", it is not needed}} |
{{Warning|SIP ALG: Because many implementations of SIP ALG are not working correctly (bug or incompatibility with some phones), we have configured the VoIP platform to handle NAT all the time. SO PLEASE DO NOT USE "SIP ALG", it is not needed}} |
||
Line 10: | Line 5: | ||
= |
=Configuration= |
||
== |
==Firewall NAT and QOS configuration== |
||
* |
*'''NAT Timeout''': Set the NAT/firewall UDP timeout to a minimum of 30s for SIP/UDP and 600s for SIP/TCP |
||
** |
**ex: <font color="green">[[NOC:Hardware:Sonicwall|SonicWall]] / [[Tools:iptables|Iptables]] are OK by default => 30s</font> |
||
** |
**ex: <font color="green">[[VoIP:Hardware:Thomson Tips|Thomson / Technicolor]] are OK by default => 124s</font> |
||
* |
*'''QOS''': You need to reserve ''100kbps per concurrent call'' and ''100 kbps per 10 BLF NOTIFY message'' (LED blinking in the same time on the phones) |
||
* |
*'''SIP ALG''': To disable ( cf warning above) |
||
* |
*'''MTU''': Please make sure you are using the good MTU value on the LAN and WAN interface of your firewall |
||
** |
**1500 on the LAN |
||
** |
**1500 on the WAN if Firewall is only doing routing |
||
** |
**1492 on the WAN if Firewall is doing PPPoE |
||
{{Warning|On Sonicwalls, if you have a MTU 1492 on the WAN, please set "Do not send ICMP Fragmentation Needed for outbound packets over the Interface MTU", otherwise it will break calls for snom phones that will display "Network Failure", cf screenshot below}} |
{{Warning|On Sonicwalls, if you have a MTU 1492 on the WAN, please set "Do not send ICMP Fragmentation Needed for outbound packets over the Interface MTU", otherwise it will break calls for snom phones that will display "Network Failure", cf screenshot below}} |
||
== |
==Network and NAT setup : STUN / TURN / externip / SIP ALG== |
||
{{Warning|Please do not set up any NAT detection, no STUN, no TURN, no SIP ALG, no externip !}} |
{{Warning|Please do not set up any NAT detection, no STUN, no TURN, no SIP ALG, no externip !}} |
||
* |
*'''Problem 1''': The usage or STUN or TURN or SIP ALG is useful to perform some peer to peer VoIP communication, but these protocols are not working in 100% of cases ( i.e: when using symmetrical NAT (almost all firewall now), or having a firewall that do not support hairpin or do not allow LAN to LAN communication ( like in Hotel Rooms ) ) |
||
* |
*'''Problem 2''': The other problem is that some implementations of these protocols are buggy on some equipments ( phone or PBX or firewall ) |
||
* |
*'''Conclusion''': Since these protocols are not working in all cases and are sometimes buggy, the VTX VoIP platform is always handling NAT detection and all VoIP stream goes via the VTX VoIP platform. Consequently, no need to enable these protocols |
||
⚫ | |||
⚫ | |||
Line 44: | Line 38: | ||
{{Notice|By default a firewall performing NAT should be stateful and might allow any PC or phone to connect from the LAN to the internet, if you kept the default mode, you can skip this section. If by default you decided to block everything for outgoing traffic (i.e: by default PC and Phone on the LAN cannot connect to the internet) except if it is explicitly allowed, then use this section where all needed traffic is listed}} |
{{Notice|By default a firewall performing NAT should be stateful and might allow any PC or phone to connect from the LAN to the internet, if you kept the default mode, you can skip this section. If by default you decided to block everything for outgoing traffic (i.e: by default PC and Phone on the LAN cannot connect to the internet) except if it is explicitly allowed, then use this section where all needed traffic is listed}} |
||
=== |
===Phone / VPBX / Connect / Firewall rules=== |
||
{{Warning|1=Some customer might complain that the 212.147.44.0/22 is too big, in this case, please use 212.147.47.208/28 instead in the following rules (which is the current Production platform ). This /22 contains all our VoIP infrastructures for Lab + PreProd + Prod, that is why it is so big ( contains 1024 IPs ).<br/> If you wish to know which IP is being used right now by your phones for SIP/SIPS and RTP/SRTP, you need to do a DNS resolution of your SIP domain. It should be right now 212.147.47.217 (for VPBX) or 212.147.47.218 (for ConnectPBX |
{{Warning|1=Some customer might complain that the 212.147.44.0/22 is too big, in this case, please use 212.147.47.208/28 instead in the following rules (which is the current Production platform ). This /22 contains all our VoIP infrastructures for Lab + PreProd + Prod, that is why it is so big ( contains 1024 IPs ).<br/> If you wish to know which IP is being used right now by your phones for SIP/SIPS and RTP/SRTP, you need to do a DNS resolution of your SIP domain. It should be right now 212.147.47.217 (for VPBX) or 212.147.47.218 (for ConnectPBX). WARNING, this IPs might change over time, this is why we gave you a wider range. If in the future we change this IP and you setup too narrow rules, your phones won't be able to connect anymore}} |
||
{{Warning|1=If you own Yealink phones, you will need to allow them to perform NTP queries towards pool.ntp.org which has dynamic IPs ( so allow NTP towards all the internet ), otherwise it won't boot. As a workaround, you could try to redirect NTP queries and have them answered}} |
{{Warning|1=If you own Yealink phones, you will need to allow them to perform NTP queries towards pool.ntp.org which has dynamic IPs ( so allow NTP towards all the internet ), otherwise it won't boot. As a workaround, you could try to redirect NTP queries and have them answered}} |
||
{{Notice|1=@VTX: If you do alter the list below, please inform NOC team to have the ACLs on the LNS and if needed the STS of VTXBox updated}} |
{{Notice|1=@VTX: If you do alter the list below, please inform NOC team to have the ACLs on the LNS and if needed the STS of VTXBox updated}} |
||
* |
*'''SIP signaling''' that allows your phone to call out and to receive calls |
||
** |
**'''IP range''': ''212.147.44.0/22 (from 212.147.44.0 to 212.147.47.255)''. |
||
** |
**'''Port range''': ''UDP/5060 + TCP/5060 + TCP/5061 (for SIP/TLS)'' |
||
* |
*'''RTP and RTCP packets''' that transport the voice and quality call data |
||
** |
**'''IP range''': ''212.147.44.0/22 (from 212.147.44.0 to 212.147.47.255)'' |
||
**'''Port range''': ''all UDP ports'' ( <font color="red"><b>WARNING : If you really need a range, use 1024->65535. DO NOT TRY TO GUESS THE PORT RANGE WE ARE USING, IT IS CHANGING OVER TIME WITH CAPACITY INCREASE</b></font> ) |
|||
** '''Port range''': ''all UDP ports'' |
|||
* |
*'''HTTP/HTTPs''' for phone auto-configuration |
||
** |
**'''IP range''': ''secure-provisioning.snom.com + rcs.aastra.com + prov.gigaset.net + profile.gigaset.net + suota.gigaset.com + rps.yealink.com + 212.40.12.0/24 + 212.147.44.0/22'' |
||
** |
**'''Port range''': ''TCP/80 + TCP/443'' |
||
* |
*'''LDAP/LDAPS''' for Centralized Kiosk Directory |
||
** |
**'''IP range''': 212.40.12.0/24 |
||
** |
**'''Port range''': TCP/389 + TCP/636 |
||
* |
*'''DNS/NTP''' for DNS queries and NTP time updated |
||
** |
**'''IP range''': ''rs0[1-4].vtx.ch'' + ( <font color="red"><b>WARNING: Allow "*" in case you own Yealink phones because the Yealink won't boot if there is no answer towards pool.ntp.org which has dynamic IPs </b></font>) |
||
** |
**'''Port''': ''UDP/53 + TCP/53 + UDP/123'' |
||
* |
*'''Syslog''': Used for VTX Support to help debug any problem with auto provisioned phones |
||
** |
**'''IP range''': ''212.147.99.16/28'' |
||
** |
**'''Port range''': UDP/514 |
||
NB: Regarding RTP configuration, we do not recommend to set a UDP port range restriction because we can add ranges without notice if needed |
|||
Line 93: | Line 86: | ||
-A FORWARD -p udp -m multiport --dports 514 -d 212.147.99.16/28 -j ACCEPT |
-A FORWARD -p udp -m multiport --dports 514 -d 212.147.99.16/28 -j ACCEPT |
||
⚫ | |||
{{Warning|We have enabled Media Bypass to have the Secured RTP traffic going directly from the Teams Phone to VTX SBC without going via the Microsoft Teams Cloud to reduce call latency. So if you have restrictions on your firewall, you also need to allow VTX Specific IPs}} |
|||
⚫ | |||
{{Warning|Microsoft did enlarged IP Ranges used by Microsoft in June 2022. Thanks to recheck your Firewall settings and adapt ranges if needed}} |
|||
⚫ | |||
*'''SIP Signaling''': Here are the FQDN to use to define the destination of the trunk |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
* |
*'''SIP/TLS Firewalling''': The SIP/TLS flows could come from one of these IPs and TCP Range |
||
**IP Ranges: 52.112.0.0/14 + 52.120.0.0/14 |
|||
⚫ | |||
**SIP/TLS Source Port Range: 1024 – 65535 |
|||
⚫ | |||
⚫ | |||
* |
*'''RTP Transport Relay Firewalling''': The media traffic flows to and from a separate service in the Microsoft Cloud. The IP range for Media traffic: |
||
** IP |
**RTP IP Ranges: 52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254). + 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254). |
||
** |
**UDP/SRTP Source Port Range : 3478-3481 and 49152 – 53247 |
||
* |
*'''RTP Media Bypass Firewalling''': This is used for Media Bypass |
||
** |
**RTP IP Ranges: 52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254). + 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254). |
||
** |
**UDP/SRTP Source Port Range : 50000 – 59999 |
||
* |
*'''VTX RTP Media Bypass Range''': This is used by VTX SBCs |
||
** |
**RTP IP Range: 212.147.44.0/22 (IP addresses from 212.147.44.0 to 212.147.47.255). |
||
** |
**UDP/SRTP Source Port Range : 10000 - 39999 |
||
=== |
===VTX GeoIP Restriction=== |
||
{{:FAQ:VoIP:GeoIP_Filtering}} |
|||
{{Notice|1=This feature has been implemented in 2012}} |
|||
{{Warning|By default, outgoing billed calls are only possible from a Switzerland IP, this change be changed to Europe/World or ACL from a Kiosk Admin account, see "Outgoing Calls" below}} |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
Here are the different GeoIP restrictions on the Telephony platform |
|||
* '''Phone auto provisioning''': is only working from Switzerland and France ( cannot be changed ) |
|||
* '''Register and Incoming Calls''': Open to the whole world |
|||
* '''Outgoing Calls''': Billed outgoing calls are only allowed from Switzerland by default ( This setting can be changed from customer Admin Kiosk interface to open it to Europe or World or some specific IPs) (@VTX: Please refer to [[FAQ:VoIP#GeoIP_Filtering]] for more details) |
|||
[[File:GeoLimit_Kosk.png|444x444px]] |
|||
* These settings can be found under "My Services - Telephony - Call restrictions - IP Filtering" |
|||
* The "IP Filtering" tab is only visible if you access the kiosk from a swiss IP address (otherwise this tab is hidden) |
|||
* A customer can't do any adjustments if he is already abroad. In such case these changes would have to be done by someone who has access from an IP in Switzerland, or uses TeamViewer / Remote access / VPN / proxy server for the modification. |
|||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
'''ping s1.12345.bus.ipvoip.ch''' |
'''ping s1.12345.bus.ipvoip.ch''' |
||
PING vtx.res.ipvoip.ch (212.147.47.217) 56(84) bytes of data. |
PING vtx.res.ipvoip.ch (212.147.47.217) 56(84) bytes of data. |
||
Line 148: | Line 133: | ||
rtt min/avg/max/mdev = 7.659/8.041/8.324/0.289 ms |
rtt min/avg/max/mdev = 7.659/8.041/8.324/0.289 ms |
||
* |
*''SIP is also allowed to work on TCP, so you can use telnet to verify your connectivity towards the platform (you need to see "connected" message)'' |
||
'''telnet s1.12345.bus.ipvoip.ch 5060''' |
'''telnet s1.12345.bus.ipvoip.ch 5060''' |
||
Trying 212.147.47.217... |
Trying 212.147.47.217... |
||
Line 155: | Line 141: | ||
⚫ | |||
⚫ | |||
⚫ | |||
⚫ | |||
{{Blackboxwarning|Please do not forget to enable '''Consistant NAT''' on the Sonicwall, we have noticed bugs on Sonicwall with Downstream audio problem after some time when disabled !}} |
{{Blackboxwarning|Please do not forget to enable '''Consistant NAT''' on the Sonicwall, we have noticed bugs on Sonicwall with Downstream audio problem after some time when disabled !}} |
||
Line 165: | Line 150: | ||
You can find here the VoiP parameters for the sonicwall validate by VTX. |
You can find here the VoiP parameters for the sonicwall validate by VTX. |
||
* |
*'''Modifications to perform on the Sonicwall''' |
||
** |
**'''VoIP''' / '''Settings''' / '''Enable Consistant NAT''' => [http://help.mysonicwall.com/sw/eng/1531/ui2/13000/Firewall/VoIP.htm Sonicwall Doc Helper] |
||
** |
**On the WAN interface, please set '''"Do not send ICMP Fragmentation Needed for outbound packets over the Interface MTU"''' |
||
<table> |
<table> |
||
Line 178: | Line 163: | ||
<br> |
<br> |
||
== |
==Watchguard M400 / Snom== |
||
{{Warning|On Watchguard, if used together with Snom, possible '''call cut''' and '''audio problemes''' - Watchguard should get updated to Firmware: 12.1.3.B563398 (Fireware OS)}} |
{{Warning|On Watchguard, if used together with Snom, possible '''call cut''' and '''audio problemes''' - Watchguard should get updated to Firmware: 12.1.3.B563398 (Fireware OS)}} |
||
== |
==Connection UPC / check Modem== |
||
{{Notice|we have some customers with an UPC connection using VTX VoIP-Services and having problems which could get solved by get a different type of UPC Modem (@VTX: cf example in G2K ticket 1622489)}} |
{{Notice|we have some customers with an UPC connection using VTX VoIP-Services and having problems which could get solved by get a different type of UPC Modem (@VTX: cf example in G2K ticket 1622489)}} |
Latest revision as of 14:53, 24 June 2024
SIP ALG: Because many implementations of SIP ALG are not working correctly (bug or incompatibility with some phones), we have configured the VoIP platform to handle NAT all the time. SO PLEASE DO NOT USE "SIP ALG", it is not needed |
STUN / TURN: Because STUN is not working in call cases (like symmetrical NAT), we have configured the VoIP platform to handle NAT all the time. SO PLEASE DO NOT USE "STUN" nor "TURN", it is not needed |
If you have trouble with your firewall, we recommend to start with a simple configuration allowing all streams from LAN to WAN, then if it is working, you can add filtering rules |
Configuration[edit | edit source]
Firewall NAT and QOS configuration[edit | edit source]
- NAT Timeout: Set the NAT/firewall UDP timeout to a minimum of 30s for SIP/UDP and 600s for SIP/TCP
- ex: SonicWall / Iptables are OK by default => 30s
- ex: Thomson / Technicolor are OK by default => 124s
- QOS: You need to reserve 100kbps per concurrent call and 100 kbps per 10 BLF NOTIFY message (LED blinking in the same time on the phones)
- SIP ALG: To disable ( cf warning above)
- MTU: Please make sure you are using the good MTU value on the LAN and WAN interface of your firewall
- 1500 on the LAN
- 1500 on the WAN if Firewall is only doing routing
- 1492 on the WAN if Firewall is doing PPPoE
On Sonicwalls, if you have a MTU 1492 on the WAN, please set "Do not send ICMP Fragmentation Needed for outbound packets over the Interface MTU", otherwise it will break calls for snom phones that will display "Network Failure", cf screenshot below |
Network and NAT setup : STUN / TURN / externip / SIP ALG[edit | edit source]
Please do not set up any NAT detection, no STUN, no TURN, no SIP ALG, no externip ! |
- Problem 1: The usage or STUN or TURN or SIP ALG is useful to perform some peer to peer VoIP communication, but these protocols are not working in 100% of cases ( i.e: when using symmetrical NAT (almost all firewall now), or having a firewall that do not support hairpin or do not allow LAN to LAN communication ( like in Hotel Rooms ) )
- Problem 2: The other problem is that some implementations of these protocols are buggy on some equipments ( phone or PBX or firewall )
- Conclusion: Since these protocols are not working in all cases and are sometimes buggy, the VTX VoIP platform is always handling NAT detection and all VoIP stream goes via the VTX VoIP platform. Consequently, no need to enable these protocols
Access List[edit | edit source]
By default a firewall performing NAT should be stateful and might allow any PC or phone to connect from the LAN to the internet, if you kept the default mode, you can skip this section. If by default you decided to block everything for outgoing traffic (i.e: by default PC and Phone on the LAN cannot connect to the internet) except if it is explicitly allowed, then use this section where all needed traffic is listed |
Phone / VPBX / Connect / Firewall rules[edit | edit source]
Some customer might complain that the 212.147.44.0/22 is too big, in this case, please use 212.147.47.208/28 instead in the following rules (which is the current Production platform ). This /22 contains all our VoIP infrastructures for Lab + PreProd + Prod, that is why it is so big ( contains 1024 IPs ). If you wish to know which IP is being used right now by your phones for SIP/SIPS and RTP/SRTP, you need to do a DNS resolution of your SIP domain. It should be right now 212.147.47.217 (for VPBX) or 212.147.47.218 (for ConnectPBX). WARNING, this IPs might change over time, this is why we gave you a wider range. If in the future we change this IP and you setup too narrow rules, your phones won't be able to connect anymore |
If you own Yealink phones, you will need to allow them to perform NTP queries towards pool.ntp.org which has dynamic IPs ( so allow NTP towards all the internet ), otherwise it won't boot. As a workaround, you could try to redirect NTP queries and have them answered |
@VTX: If you do alter the list below, please inform NOC team to have the ACLs on the LNS and if needed the STS of VTXBox updated |
- SIP signaling that allows your phone to call out and to receive calls
- IP range: 212.147.44.0/22 (from 212.147.44.0 to 212.147.47.255).
- Port range: UDP/5060 + TCP/5060 + TCP/5061 (for SIP/TLS)
- RTP and RTCP packets that transport the voice and quality call data
- IP range: 212.147.44.0/22 (from 212.147.44.0 to 212.147.47.255)
- Port range: all UDP ports ( WARNING : If you really need a range, use 1024->65535. DO NOT TRY TO GUESS THE PORT RANGE WE ARE USING, IT IS CHANGING OVER TIME WITH CAPACITY INCREASE )
- HTTP/HTTPs for phone auto-configuration
- IP range: secure-provisioning.snom.com + rcs.aastra.com + prov.gigaset.net + profile.gigaset.net + suota.gigaset.com + rps.yealink.com + 212.40.12.0/24 + 212.147.44.0/22
- Port range: TCP/80 + TCP/443
- LDAP/LDAPS for Centralized Kiosk Directory
- IP range: 212.40.12.0/24
- Port range: TCP/389 + TCP/636
- DNS/NTP for DNS queries and NTP time updated
- IP range: rs0[1-4].vtx.ch + ( WARNING: Allow "*" in case you own Yealink phones because the Yealink won't boot if there is no answer towards pool.ntp.org which has dynamic IPs )
- Port: UDP/53 + TCP/53 + UDP/123
- Syslog: Used for VTX Support to help debug any problem with auto provisioned phones
- IP range: 212.147.99.16/28
- Port range: UDP/514
Here is an overview of an Tools:iptables configuration
### Allow SIP Signalisation ### -A FORWARD -p udp -m multiport --dports 5060 -d 212.147.44.0/22 -j ACCEPT -A FORWARD -p tcp -m multiport --dports 5060,5061 -d 212.147.44.0/22 -j ACCEPT # Allow all TCP ports for MS Skype for Business -A FORWARD -p tcp -d 212.147.44.0/22 -j ACCEPT ### Allow RTP (voice) #### -A FORWARD -p udp -d 212.147.44.0/22 -j ACCEPT ### Allow HTTP/HTTPS ### -A FORWARD -p tcp -m multiport --dports 80,443 -d secure-provisioning.snom.com,rcs.aastra.com,prov.gigaset.net,profile.gigaset.net,rps.yealink.com,212.40.12.0/24,212.147.44.0/22 -j ACCEPT ### Allow LDAP/LDAPS ### -A FORWARD -p tcp -m multiport --dports 389,636 -d 212.40.12.0/24 -j ACCEPT ### Allow DNS/NTP ### -A FORWARD -p udp -m multiport --dports 53,123 -d rs01.vtx.ch,rs02.vtx.ch,rs03.vtx.ch,rs04.vtx.ch -j ACCEPT -A FORWARD -p tcp -m multiport --dports 53 -d rs01.vtx.ch,rs02.vtx.ch,rs03.vtx.ch,rs04.vtx.ch -j ACCEPT ### Allow all NTP servers for Yealink phones that needs NTP towards pool.ntp.org to work at boot process otherwise they won't boot, and since pool.ntp.org is dynamic, all NTP traffic needs to be allowed ### -A FORWARD -p udp -m multiport --dports 123 -j ACCEPT ### Allow Syslog ### -A FORWARD -p tcp -m multiport --dports 514 -d 212.147.99.16/28 -j ACCEPT -A FORWARD -p udp -m multiport --dports 514 -d 212.147.99.16/28 -j ACCEPT
Teams Connect/Virtual Firewall Rules[edit | edit source]
We have enabled Media Bypass to have the Secured RTP traffic going directly from the Teams Phone to VTX SBC without going via the Microsoft Teams Cloud to reduce call latency. So if you have restrictions on your firewall, you also need to allow VTX Specific IPs |
Microsoft did enlarged IP Ranges used by Microsoft in June 2022. Thanks to recheck your Firewall settings and adapt ranges if needed |
- Information: The list of List of IPs for Office 365 services for Skype for Business and Microsoft Teams available for Switzerland is available at https://docs.microsoft.com/en-us/microsoftteams/direct-routing-plan#sip-signaling-fqdns-and-firewall-ports
- SIP Signaling: Here are the FQDN to use to define the destination of the trunk
- sip.pstnhub.microsoft.com – Global FQDN – must be tried first.
- sip2.pstnhub.microsoft.com – Secondary FQDN – geographically maps to the second priority region.
- sip3.pstnhub.microsoft.com – Tertiary FQDN – geographically maps to the third priority region.
- SIP/TLS Firewalling: The SIP/TLS flows could come from one of these IPs and TCP Range
- IP Ranges: 52.112.0.0/14 + 52.120.0.0/14
- SIP/TLS Source Port Range: 1024 – 65535
- RTP Transport Relay Firewalling: The media traffic flows to and from a separate service in the Microsoft Cloud. The IP range for Media traffic:
- RTP IP Ranges: 52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254). + 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254).
- UDP/SRTP Source Port Range : 3478-3481 and 49152 – 53247
- RTP Media Bypass Firewalling: This is used for Media Bypass
- RTP IP Ranges: 52.112.0.0/14 (IP addresses from 52.112.0.1 to 52.115.255.254). + 52.120.0.0/14 (IP addresses from 52.120.0.1 to 52.123.255.254).
- UDP/SRTP Source Port Range : 50000 – 59999
- VTX RTP Media Bypass Range: This is used by VTX SBCs
- RTP IP Range: 212.147.44.0/22 (IP addresses from 212.147.44.0 to 212.147.47.255).
- UDP/SRTP Source Port Range : 10000 - 39999
VTX GeoIP Restriction[edit | edit source]
By default, outgoing billed calls are only possible from a Switzerland or France based on customer profile, this restriction can be changed to Europe/World or ACL from a Customer Selfcare Portal with an Admin account, see "Outgoing Calls" below |
Default GeoIP restriction[edit | edit source]
There are the different GeoIP restrictions on the Telephony platform:
- Physical phone auto provisioning (CH/FR): is only working from Switzerland and France (other location could be added on request to VTX Support Team)
- VTX Softphones (World) : Could be used anywhere in the world ( but you still need to allow outgoing calls if calling from abroad, cf below )
- Register and Incoming Calls (World): Open to the whole world
- Outgoing Calls (CH/FR/Europe/World/ACLs): Billed outgoing calls are only allowed from Switzerland or France (depending on customer type) by default ( This setting can be changed from customer Admin Kiosk interface to open it to Europe or World or some specific IPs)
- Kiosk SIP Credentials (CH/FR): Kiosk SIP account credentials are only accessible from Switzerland or France (depending on customer type) for security reason, no workaround available ( cf below ).
Kiosk : Allow calls from Europe / World or restrict it to ACLs[edit | edit source]
The "IP Filtering" tab is only visible if you access the kiosk from a swiss IP address (otherwise this tab is hidden). A customer can't do any adjustments if he is already abroad. In such case these changes would have to be done by someone who has access from an IP in Switzerland, or uses Remote access / VPN / proxy server / contact VTX Support for the modification. |
- Information: Most of our customers are using their phone from Switzerland, so from a security point of view, it was wise to restrict by default the usage of VoIP telephony from Switzerland, but also allowing our customer to change this behavior per number or per service
- Symptoms: Your are not able to dial an external number while using a phone abroad. You get an error saying that your restrictions or limitations do not allow you to pass this call
- Problematic: Allow some or all phones of a service to be used in other countries, or from some IPs
- Solution: Follow the procedure below
- (Change allowed Country in Kiosk): Connect to https://kiosk.vtx.ch with your VTX Service Administrator Credentials
- Go in section "My Services / Telephony / Call restrictions / IP Filtering"
- Read documentation and adapt it to fit your needs
Check the country of your IP in the database[edit | edit source]
- Problematic: You wish to verify the country location of your connection IP
- Solution: Follow procedure below
- (Verify your connection country) You can verify the country of your connection IP in https://www.maxmind.com/en/locate-my-ip-address or https://www.maxmind.com/en/geoip-demo
Restricted call on Tuesday morning - Wrong Country : Submit a correction[edit | edit source]
Our GeoIP country database is updated every Tuesday at 08:00 |
- Information:
- (VTX IPs always set to CH) We made sure that the "VTX" IPs will remain set in Switzerland ( reference #159010 )
- (Maxmind GeoIP Accuracy) We are using the Maxmind Country Paid database with an accuracy of 99,8% to check from which country the call is passed, cf https://www.maxmind.com/en/geoip2-country-database
- Symptoms: On Tuesday morning, you start to have your outgoing calls now working anymore with an error "Your restriction or limitation to not allow you to call out"
- Possible Explanation: Your connection IP did switch country because of the geoip database update
- Problematic: You wish to submit a correction of the country of your IPs
- Solution: Follow procedure below
- In case of false data, you can submit a correction in https://www.maxmind.com/en/geoip-data-correction-request
Other Network Restrictions[edit | edit source]
Some firewalls or remote ISP might also restrict VoIP, you can use the following tests to verify connectivity |
If you have some connectivity problem, please perform the tests below, check the trace on your firewall and inform our support from which IP did you test it and at which exact time |
- Ping the VoIP platform which is opened to ping from the whole world
ping s1.12345.bus.ipvoip.ch PING vtx.res.ipvoip.ch (212.147.47.217) 56(84) bytes of data. 64 bytes from fix.47.147.212.vtx.ch (212.147.47.217): icmp_seq=1 ttl=53 time=7.65 ms 64 bytes from fix.47.147.212.vtx.ch (212.147.47.217): icmp_seq=2 ttl=53 time=8.32 ms 64 bytes from fix.47.147.212.vtx.ch (212.147.47.217): icmp_seq=3 ttl=53 time=8.14 ms --- s1.12345.bus.ipvoip.ch ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 7.659/8.041/8.324/0.289 ms
- SIP is also allowed to work on TCP, so you can use telnet to verify your connectivity towards the platform (you need to see "connected" message)
telnet s1.12345.bus.ipvoip.ch 5060 Trying 212.147.47.217... Connected to s1.12345.bus.ipvoip.ch. Escape character is '^]'.
Vendor Specific Setup[edit | edit source]
Sonicwall VoiP Configuration[edit | edit source]
If you have trouble with your firewall, we recommend to start with a simple configuration allowing all streams from LAN to WAN, then if it is working, you can add filtering rules |
You can find here the VoiP parameters for the sonicwall validate by VTX.
- Modifications to perform on the Sonicwall
- VoIP / Settings / Enable Consistant NAT => Sonicwall Doc Helper
- On the WAN interface, please set "Do not send ICMP Fragmentation Needed for outbound packets over the Interface MTU"
Watchguard M400 / Snom[edit | edit source]
On Watchguard, if used together with Snom, possible call cut and audio problemes - Watchguard should get updated to Firmware: 12.1.3.B563398 (Fireware OS) |
Connection UPC / check Modem[edit | edit source]
we have some customers with an UPC connection using VTX VoIP-Services and having problems which could get solved by get a different type of UPC Modem (@VTX: cf example in G2K ticket 1622489) |