Categories
Blog Knowledge Base

Gamma’s Gateway migration and SIP issues

Over the last few weeks and possibly going on for a few more Gamma Telecom are migrating users from their MSX SBCs to their ‘new’ SWe SBCs, and as side effect of this change is that they now do not support non-symetrical nat translation of RTP traffic

Their previous SBCs and like many other carriers do not have an issue with this and in the words of Twilio’s notes below they support both methods

** When Symmetric RTP is enabled Twilio will detect where the remote RTP stream is coming from and start sending RTP to that destination instead of the one negotiated in the SDP. Please note that this setting is more vulnerable to RTP attacks.

When Symmetric RTP is disabled, Twilio will send RTP to the destination negotiated in the SDP. This setting is considered to be more secure and therefore recommended.

On making support calls to Gamma initially they just seem to tell users that the RTP is being sent from a port that isn’t specified in the SDP, and yes that is correct, But Gamma being Gamma and even though they will have had numerous calls they don’t go any further

It seems the problem is with the customer firewalls in particular pfSense:

By default, pfSense software rewrites the source port on all outgoing connections except for UDP port 500. Some operating systems do a poor job of source port randomization, if they do it at all. This makes IP address spoofing easier and makes it possible to fingerprint hosts behind the firewall from their outbound traffic. Rewriting the source port eliminates these potential (but unlikely) security vulnerabilities. Outbound NAT rules, including the automatic rules, will show  in the Static Port column on rules set to randomize the source port.

Source port randomization breaks some rare applications. The default Automatic Outbound NAT ruleset disables source port randomization for UDP 500 because it will almost always be broken by rewriting the source port. Outbound NAT rules which preserve the original source port are called Static Port rules and have  on the rule in the Static Port column. All other traffic has the source port rewritten by default.

To add a rule for a device which requires static source ports:

  • Navigate to Firewall > NATOutbound tab
  • Select Hybrid Outbound NAT rule generation
  • Click Save
  • Click  to add a new NAT rule to the top of the list
  • Configure the rule to match the traffic that requires static port, such as a source address of a PBX.
  • Check Static Port in the Translation section of the page
  • Click Save
  • Click Apply Changes

After making that change, the source port on outgoing traffic matching the rule will be preserved. **The best practice is to use strict rules when utilizing static port to avoid any potential conflict if two local hosts use the same source port to talk to the same remote server and port using the same external IP address.**

Personally I would just make this change for the UDP port range and not all UDP ports as this could cause problem with traffic such a port 5060 when multiple servers or phones are on a site.

We have also been made aware of another issue with respect to call diversion to external numbers. By deafault Asterisk and many other IP PBXs set a diversion header in the 181 message giving the device that diverted the call and reason. in most cases this will be the extension number so the header will look like:

 Diversion: <sip:477@aaa.bbb.ccc.ddd>;reason=unconditional

This seems to cause issues at Gamma and they reject the call as it seems they are setting the callerid from this info.

To overcome this issue for chan_sip set ‘send_diversion = no’ in the general setting of sip.conf or in the “Other SIP Settings” fields in the Advanced sip setting menu. For PJSIP add it to the pjsip.endpoint_custom_post.conf file as below.

[PJSIPTwilio](+)
send_diversion=no

[GRAMMA_TEST](+)
send_diversion=no

And this seems to solve the problem.

To be honest we have only seen the problem with Gamma trunks and having tested with other suppliers and found they are not affected.

Gammas reson for this is as follows: “After reviewing the divert packet, I can see in the message header that the Diversion header is set to divert to “477”. I would recommend to change this to the full CLI you wish to forward the call to as I believe the system is trying to call “477” which wouldn’t be classed as a valid number. The 603 error you are seeing from your side would be in relation to OFCOMS national number length violation.”

See the Packet below

Session Initiation Protocol (181)
    Status-Line: SIP/2.0 181 Call is being forwarded
        Status-Code: 181
        [Resent Packet: False]
        [Request Frame: 22149]
        [Response Time (ms): 187]
    Message Header
        Via: SIP/2.0/UDP xxx.yyy.aaa.zzz:5060;branch=z9hG4bK04B82da620259a59a1a;received=xxx.yyy.aaa.zzz;rport=5060
            Transport: UDP
            Sent-by Address: xxx.yyy.aaa.zzz
            Sent-by port: 5060
            Branch: z9hG4bK04B82da620259a59a1a
            Received: xxx.yyy.aaa.zzz
            RPort: 5060
        From: <sip:01234567890@xxx.yyy.aaa.zzz>;tag=gK0441ee4f
            SIP from address: sip:01234567890@xxx.yyy.aaa.zzz
            SIP from tag: gK0441ee4f
        To: <sip:07890123456@aaa.bbb.ccc.ddd>;tag=as24643c1b
            SIP to address: sip:07890123456@aaa.bbb.ccc.ddd
            SIP to tag: as24643c1b
        Call-ID: 71571273_130153708@xxx.yyy.aaa.zzz
        [Generated Call-ID: 71571273_130153708@xxx.yyy.aaa.zzz]
        CSeq: 321899 INVITE
            Sequence Number: 321899
            Method: INVITE
        Server: FPBX-16.0.40.7(18.9)
        Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
        Supported: replaces, timer
        Session-Expires: 1800;refresher=uas
        Contact: <sip:07890123456@aaa.bbb.ccc.ddd:5060>
            Contact URI: sip:07890123456@aaa.bbb.ccc.ddd:5060
                Contact URI User Part: 07890123456
                Contact URI Host Part: aaa.bbb.ccc.ddd
                Contact URI Host Port: 5060
        Diversion: <sip:477@aaa.bbb.ccc.ddd>;reason=unconditional
        Content-Length: 0

Now the RFC says :

“When a diversion occurs, a Diversion header SHOULD be added to the forwarded request or forwarded 3xx response. The Diversion header MUST contain the Request-URI of the request prior to the diversion. The Diversion header SHOULD contain a reason that the diversion occurred.”

Which is what happens, Gamma seem to have confused what the diversion header does as they seem to assume its setting the diversion destination or outbound caller ID, Neither of which are the uses for the Diversion header.

‘I will add updates here as and when they become available.’

Categories
Asterisk Support Blog Elastix Support FreePBX Knowledge Base Security

Keeping the Bots out and allowing your friends in

Since this post was originally written things have advanced, FreePBX has an integrated firewall with intrusion detection using Fail2Ban, and this should always be enabled even if system is on premise.

Another major step forward in protection is APIBAN this is a client program that helps prevent unwanted SIP traffic by identifying addresses of known bad actors before they attack your system. Bad bots are collected through globally deployed honeypots. To use APIBAN you will need a key these are obtained from here . More details on API ban are here if you are interested in using it in different situations.

To simplify installation on Freepbx based systems I have simple script that downloads and install it, this can be downloaded here or from the command line of the server as follows:

wget https://freeaccesspublic.s3.eu-west-2.amazonaws.com/apiban.sh
Make it an executable : chmod +x  apiban.sh
then run the script : ./apiban.sh your_api_key

If you dont add your APIKEY on the command line vi will open and you can add it manually. The script will then initially run the client which will take a few seconds to download the initial set of bots, then it will add a line to the crontab file and restart the cron daemon. the timing of the cronjob is randomised to be between every 4 and 22 minutes.

We have seen many Bots attacking Asterisk servers, Interestingly its not always good old sipvicious anymore but a Windows program called sipcli and originating mainly from the US and Germany.

Normally our iptables firewalls are updated but for some reason these keep getting through, So we have now based rules on the User-Agent in iptables as well

Here are a few examples to get rid of many of the favourites

-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: friendly-scanner" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipcli" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A INPUT -p udp -m udp --dport 5060 -m string --string "User-Agent: VaxSIPUserAgent" --algo bm --to 65535 -j DROP

For Freepbx format add following to the Firewalls custom rules


-A fpbxreject -p udp --dport 5060:5261 -m string --string "REGISTER sip:server.domain.co.uk" --algo bm -j ACCEPT
-A fpbxreject -p udp --dport 5060:5261 -m string --string "REGISTER sip:" --algo bm -j DROP
-A fpbxreject -p tcp --dport 5060:5261 -m string --string "REGISTER sip:server.domain.co.uk" --algo bm -j ACCEPT
-A fpbxreject -p tcp --dport 5060:5261 -m string --string "REGISTER sip:" --algo bm -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "sip:a'or'3=3--@" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: PolycomSoundPointIP SPIP_550 UA 3.3.2.0413" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: Avaya IP Phone 1120E" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: Cisco-SIPGateway/IOS-15.2.4.M5" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: PolycomVVX-VVX_401-UA5.4.1.18405" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: eyeBeam release 3006o stamp 17551" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: owenee" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: owenee" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: Custom" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: Custom" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: SIP" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: SIP" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: gazllove" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: gazllove" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: pplsip" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: pplsip" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: sipcli" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: sipcli" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: sipvicious" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: sip-scan" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: sip-scan" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: sipsak" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: sipsak" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: sundayddr" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: sundayddr" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: friendly-scanner" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: friendly-scanner" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: iWar" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: iWar" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: CSipSimple" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: CSipSimple" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: SIVuS" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: SIVuS" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: Gulp" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: Gulp" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: sipv" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: sipv" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: smap" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: smap" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: friendly-request" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: friendly-request" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: VaxIPUserAgent" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: VaxIPUserAgent" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: VaxSIPUserAgent" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: VaxSIPUserAgent" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: siparmyknife" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: siparmyknife" --algo bm --to 65535 -j DROP
-A fpbxreject -p udp -m udp --dport 5060:5261 -m string --string "User-Agent: Test" --algo bm --to 65535 -j DROP
-A fpbxreject -p tcp -m tcp --dport 5060:5261 -m string --string "User-Agent: Test" --algo bm --to 65535 -j DROP

Also its worth adding these ranges as little good will ever come from them

# Ponytelecom ranges
-A INPUT -s 62.210.0.0/16 -j DROP
-A INPUT -s 195.154.0.0/16 -j DROP
-A INPUT -s 212.129.0.0/18 -j DROP
-A INPUT -s 62.4.0.0/19 -j DROP
-A INPUT -s 212.83.128.0/19 -j DROP
-A INPUT -s 212.83.160.0/19 -j DROP
-A INPUT -s 212.47.224.0/19 -j DROP
-A INPUT -s 163.172.0.0/16 -j DROP
-A INPUT -s 51.15.0.0/16 -j DROP
-A INPUT -s 151.115.0.0/16 -j DROP

# VITOX TELECOM
-A INPUT -s 77.247.109.0/255.255.255.0 -p udp -j DROP 
-A INPUT -s 185.53.88.0/24 -p udp -j DROP 
-A INPUT -s 185.53.89.0/24 -p udp -j DROP 
-A INPUT -s 37.49.224.0/24 -p udp -j DROP 
-A INPUT -s 37.49.230.0/24 -p udp -j DROP 
-A INPUT -s 37.49.231.0/24 -p udp -j DROP 
-A INPUT -s 77.247.110.0/255.255.255.0 -p udp -j DROP
Categories
Asterisk Support Knowledge Base Products and services Technical

Gradwell IP Address ranges

At Gradwell, they send internet traffic from different addresses (known as IP addresses) to allow their telephony systems to work smoothly. Below is the list of IP addresses where their VoIP (Voice over IP) traffic will come from. It’s important that your firewall allows traffic from these addresses however they recommend you don’t set it to allow only from these, just that they are included.

The reason they say don’t allow only these addresses is that there network is dynamic and may shift or new items added and we don’t want this to affect your service.

There are a couple of things you should do to ensure you get the most from the Gradwell Voice services:

  • Check your firewall filtering – is there anything being excluded?
    • If yes – Allow the IP range traffic – this will most likely be in your firewall settings or tools (they all differ so they can’t exactly point you there)
    • If no – you’re good to go
  • If you use UDP traffic then you’ll need to allow Media ports (known as RTP) with the numbers 1024 to 65535

Current ranges as of summer 2021

109.224.232.0/22 109.224.232.0 to 109.224.235.255
109.224.240.0/22 109.224.240.0 to 109.224.243.255
109.239.96.132/31 109.239.96.132 to 109.239.96.133
141.170.24.21/31 141.170.24.21 to 141.170.24.22
141.170.24.5/31 141.170.24.5 to 141.170.24.6
141.170.50.16/28 141.170.50.16 to 141.170.50.31
185.47.148.0/24 185.47.148.0 to 185.47.148.255
194.145.188.224/27 194.145.188.224 to 194.145.188.255
194.145.189.52/31 194.145.189.52 to 194.145.189.53
194.145.190.128/26 194.145.190.128 to 194.145.190.191
194.145.191.128/27 194.145.191.128 to 194.145.191.159
195.74.60.0/23 195.74.60.0 to 195.74.61.255
213.166.3.128/26 213.166.3.129 - 213.166.3.190
213.166.4.128/26 213.166.4.129 - 213.166.4.190
213.166.5.0/24 213.166.5.0 to 213.166.5.255
78.40.243.192/27 78.40.243.192 to 78.40.243.223
87.238.72.128/26 87.238.72.128 to 87.238.72.191
87.238.73.128/26 87.238.73.128 to 87.238.73.191
87.238.74.128/26 87.238.74.128 to 87.238.74.191
87.238.77.128/26 87.238.77.128 to 87.238.77.191

To simplify things a bit listed below are the ranges in common formats.

Rules for Freepbx Custom file “firewall-4.rules”

-A fpbxreject -s 109.224.232.0/22 -p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s 109.224.240.0/22 -p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	109.224.222.16/28	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	109.224.232.0/22	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	109.224.240.0/22	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	109.239.96.132/31	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	141.170.24.20/30	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	141.170.24.5/31	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	141.170.50.16/28	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	185.47.148.0/24	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	194.145.188.224/27	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	194.145.189.52/31	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	194.145.190.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	194.145.191.128/27	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	195.74.60.0/23	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	212.11.68.144/28	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	213.166.2.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	213.166.3.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	213.166.4.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	213.166.5.0/24	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	78.40.243.192/27	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	87.238.72.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	87.238.73.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	87.238.74.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A fpbxreject -s	87.238.77.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT

Rules for IPtables file

-A INPUT -s 109.224.232.0/22 -p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s 109.224.240.0/22 -p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	109.224.222.16/28	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	109.224.232.0/22	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	109.224.240.0/22	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	109.239.96.132/31	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	141.170.24.20/30	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	141.170.24.5/31	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	141.170.50.16/28	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	185.47.148.0/24	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	194.145.188.224/27	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	194.145.189.52/31	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	194.145.190.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	194.145.191.128/27	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	195.74.60.0/23	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	212.11.68.144/28	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	213.166.2.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	213.166.3.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	213.166.4.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	213.166.5.0/24	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	78.40.243.192/27	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	87.238.72.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	87.238.73.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	87.238.74.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
-A INPUT -s	87.238.77.128/26	-p udp -m udp --dport 4569:5270 -j ACCEPT
Categories
Gateways Products

Vega VoIP digital gateways

The Most Resilient VoIP Digital Gateways in Their Class

Vega VoIP digital gateways are small appliances that seamlessly connect your legacy telephony infrastructure, made up of PRI (T1, E1) or BRI lines, to IP networks. They are great for businesses with legacy phone equipment (such as a TDM PBX) who want to connect to SIP trunking services without having to spend money altering their current network infrastructure. They are also great for businesses that are already VoIP enabled at the core (with an IP-PBX) that need PSTN connectivity and require a SIP-to-TDM converter. Simply place the Vega VoIP Digital Gateway at the edge of your network, plug in your existing internet cable for VoIP connectivity and E1,T1 or BRI cables from your phone system and let the Vega VoIP Digital Gateway automatically handle the SIP signalling and voice media conversion for seamless voice and T.38 Fax integration.

Advanced Web GUI
Features an intuitive Quick Wizard which does all the hard work for you for new deployments. Flexible dialplan to allow you to make your own routes, including automatic failure detection with failover routing.

Diagnostic Tools
Web GUI based PCAP tracing tool to capture full signaling and media, eliminating the need to connect equipment for line tracing, fully compatible with wireshark.

Low and High Density Models
The Vega 100G and Vega 200G are our low density models with a maximum capacity for 30 and 60 SIP-TDM simultaneous calls. The Vega 400G is our high density model and the most flexible field upgradable unit for a maximum capacity of 120 simultaneous SIP-TDM calls.

E1/T1 & BRI Interface
Each E1/T1 interface (for Vega 100G, 200G, 400G) and BRI interface (Vega 50 BRI) can be independently configured as network side or terminal side. The Vega gateway can therefore be connected to a PBX or the PSTN.

Built-in Local Survivability
In the event of a WAN failure, IP phones behind the Vega gateway can continue to call each other, be routed to a backup switch or connected directly to the PSTN.

Vega VoIP Digital Gateway Models


Vega VoIP Digital Gateways are one of the most reliable fault tolerant SIP-to-TDM media Gateways on the market, sized for your business needs. All Sangoma hardware carries a one year warranty with options to extend.

Vega 50 BRI

Sangoma’s Vega 50 BRI VoIP Digital Gateways are a 2-4-8 port BRI appliance for up to 16 simultaneous BRI calls

 

  • Web GUI for configuration and troubleshooting
  • Featuring Quick Wizard for rapid d
    eployment
  • Onboard DSP for media translation
  • Interoperable with most legacy and VoIP carriers worldwide
  • Advanced flexible call routing with automatic failover and bypass routing
  • Built in Local Suitability in the case of WAN failure

Vega 100G

Sangoma’s Vega 100G VoIP Digital Gateways are a single port T1/E1/PRI appliance supporting up to 30 simultaneous calls.

 

  • Web GUI for configuration and troubleshooting
  • Featuring Quick Wizard for rapid deployment
  • Onboard DSP for media translation
  • Interoperable with most legacy and VoIP carriers worldwide
  • Advanced flexible call routing with automatic failover and bypass routing
  • Built in Local Suitability in the case of WAN failure

Vega 200G

Sangoma’s Vega 200G VoIP Digital Gateways are a dual port T1/E1/PRI appliance supporting up to 60 simultaneous calls.

 

  • Web GUI for configuration and troubleshooting
  • Featuring Quick Wizard for rapid deployment
  • Onboard DSP for media translation
  • Interoperable with most legacy and VoIP carriers worldwide
  • Advanced flexible call routing with automatic failover and bypass routing
  • Built in Local Suitability in the case of WAN failure

Vega 400G

Sangoma’s Vega 400G VoIP Digital Gateways are a quad port T1/E1/PRI supporting up to 120 simultaneous calls.

 

  • Web GUI for configuration and troubleshooting
  • Field upgradable licensing
  • Dedicated bypass ports for High availability
  • Support for Private Wire or Point-to-Point applications
  • Onboard DSP for media translation
  • Interoperable with most legacy and VoIP carriers worldwide
  • Advanced flexible call routing with automatic failover and bypass routing

For me details see Here 

Categories
System Status

DNS issues affecting calls and routing

On 21-10-2016 there had been a widespread DDOS attack initially in the USA. This has affected service of some of our key voice and DNS service suppliers.

We monitor many sites and run monitoring ourselves and receive status updates from suppliers.

Below are some of the recent ones and some sites reporting the issue

http://www.diario4v.com/tendencias/2016/10/21/ataque-hacker-afecta-twitter-amazon-spotify-reddit-11816.html (you will need to translate)

http://money.cnn.com/2016/10/21/technology/ddos-attack-popular-sites/

https://www.dynstatus.com/incidents/nlr4yrr162t8

Update
Dyn Managed DNS advanced service monitoring is currently experiencing issues. Customers may notice incorrect probe alerts on their advanced DNS services. Our engineers continue to monitor and investigate the issue.

Customers with questions or concerns are encouraged to reach out to our Technical Support Team.
Posted 4 minutes ago. Oct 21, 2016 - 18:23 UTC
Update
Our engineers continue to investigate and mitigate several attacks aimed against the Dyn Managed DNS infrastructure.
Posted 34 minutes ago. Oct 21, 2016 - 17:53 UTC
Update
This DDoS attack may also be impacting Dyn Managed DNS advanced services with possible delays in monitoring. Our Engineers are continuing to work on mitigating this issue.
Posted about 2 hours ago. Oct 21, 2016 - 16:48 UTC
Investigating
As of 15:52 UTC, we have begun monitoring and mitigating a DDoS attack against our Dyn Managed DNS infrastructure. Our Engineers are continuing to work on mitigating this issue.
Posted about 2 hours ago. Oct 21, 2016 - 16:06 UTC

Gradwell:

Our upstream supplier is investigating a DNS issue, which is believed to be causing the problem.

Magrethea

We are now able to confirm that two nodes on our network where impacted by DNS issues between 17:13 and 17:45 today. As many of you will be aware there have been some major DOS attacks today which impacted a number of key sites at this time so we are attributing this issue to that attack.

We will continue to monitor and apologise for the inconvenience this outage has caused our customers.

As can be seen this is out of our control and is affecting many users worldwide.

Categories
Blog Knowledge Base

BT outage on 20th July 2016

BT have confirmed that their recent outage has been ‘resolved and services restored’.

We can also confirm this as we have slowly seen all customer alarms clearing. As many customers are aware that we operate a 24×7 monitoring platform so saw this issue start and checked that there was nothing we could do in most cases but also contacted key customers to warn them that they might be issues.
Therefore, any issues that Customers have experienced this morning when connecting to services using BT connectivity (including quality issues) should now be resolved. In the event that issues are still occurring, please reboot equipment on the BT line such as Firewalls or Routers and retest. Nagios monitor screen

If you have any questions whatsoever please do not hesitate to contact us, Also if you are a
Asterisk / Freepbx reseller or user and would like affordable monitoring please get in touch as we provide Asterisk Monitoring from £25 per year.

Categories
Knowledge Base Technical

Fortigate issues such as one way audio on Call Pickup With Hosted Asterisk and other problems.

We have noted that with some Fortigate routers and firewalls come with SIP helpers enabled by default.

The customer may initially not think that there is any issue and inbound and outbound calls work as expected, But we had noted on one customer site that when they did a call pickup on another phone that was ringing in the office they would not be able to hear the caller. The caller could hear them and if they put the call on and off hold they could speak normally.

On further  investigation with wireshark we noted that the RTP port changed when the pickup took place. We tested this on other sites not using the Fortigate hardware and did not have this issue.

Below are listed the commands to clear the SIP helper settings from the Fortigate hardware.

  1. Open the Fortigate CLI from the dashboard.
  2. Enter the following commands in FortiGate’s CLI:
    • config system settings
    • set sip-helper disable
    • set sip-nat-trace disable
    • reboot the device
  3. Reopen CLI and enter the following commands – do not enter the text after //:
    • config system session-helper
    • show    //locate the SIP entry, usually 12, but can vary.
    • delete 12     //or the number that you identified from the previous command.
  4. Disable RTP processing as follows:
    • config voip profile
    • edit default
    • config sip
    • set rtp disable
  5. And finally:
    • config system settings
    • set default-voip-alg-mode kernel-helper based
    • End

on a fortigate 200D the following is the method to use

Step 1) Removing the session helper.

Run the following commands:

config system session-helper
  show

Amongst the displayed settings will be one similar to the following example:

    edit 13
        set name sip
        set protocol 17
        set port 5060

In this example the next commands would be:

delete 13
end
Step 2) Change the default –voip –alg-mode.

Run the following commands:

config system settings
set default-voip-alg-mode kernel-helper based
end
Step 3) Either clear sessions or reboot to make sure changes take effect

a) To clear sessions

The command to clear sessions applies to ALL sessions unless a filter is applied, and therefore will interrupt traffic.

diagnose system session clear

Taken from

http://kb.fortinet.com/kb/documentLink.do?externalID=FD36405

Categories
Blog Knowledge Base

Planning for a Successful VoIP deployment

Before you deploy voice-over-IP or a Hosted PBX service in your office there are a few considerations you must first address.  Switching from traditional telephone service to voice-over-IP (VoIP) requires sufficient bandwidth, a proper switch and router, and a good battery backup solution to protect you from power failures.

The key voice-over-IP requirements discussed in this article are:

Bandwidth – Determining how much bandwidth you will need for voice-over-IP in your office is your first step.

The Router – Choosing a low quality or under performing router is a costly mistake which will degrade your call quality.

Quality of Service – You must decide whether voice traffic will be separated from regular internet users or if it will share the same network.

VoIP Equipment – There are many digital office phones, soft phones, headsets and telephone adapters on the market to choose from.

Power Failures – Voice over IP does not work when the power goes out so you should install a battery backup system and possibly a Power-over-Ethernet switch if your budget permits it.

How much bandwidth do I need?
Voice over IP needs a certain amount of bandwidth in order to keep your conversations clear and free of disruptions.  Bandwidth is the amount of information which your internet connection can send and receive in a certain period of time.  Your first step should be to use an online speed test to find out what your maximum upload stream and download stream is.  We suggest you do this test using a fixed connection to the internet rather than using your wifi (wireless) connection to get accurate results.  Try to use numerous tests during different times of the day to get a good average of what you can expect from your internet connection.  Bandwidth is normally measured in kbps or kilobits per second.
You will need to have a high speed (broadband) connection to use voice-over-IP.  A typical DSL connection will be rated at 600 kbps for the upload stream and 5000 kbps on the download stream.  You will notice that your upload stream is almost always smaller than your download stream which becomes your limiting factor for using VoIP service.
Your next step is to determine how many people in your office are likely going to be using the phone at the same time.  For instance, having ten people on the phone will require ten times as much bandwidth as having one person on the phone.  Below is a chart which will help you calculate how many people can be on the phone at one time:
Ask your voice-over-IP service provider what audio codecs they offer as there is a trade off between audio quality and bandwidth usage…

Full Quality Audio (G711 Codec)\- Uses 87 kbps for each concurrent phone call (NEB)
Compressed Audio (G729 Codec)\- Uses 33 kbps for each concurrent phone call (NEB)

So the calculation for a typical DSL connection would be:

DSL connection:600 kbps upload / 5000 kbps download
Gives us (Full Quality):600 kbps / 87 kbps = 6 concurrent calls
Gives us (Compressed Quality):600 kbps / 33 kbps = 18 concurrent calls

Notice we used the upload bandwidth in our calculation as this is the limiting factor for voice-over-IP.  You also don’t want to push your connection to the limit as most cable and DSL connections do not have guarantees in terms of how much bandwidth they will deliver.  If you Internet connection drops in bandwidth at some point during the day you don’t want your call quality to be affected.  Other factors affecting voice-over-IP are the latency of your connection and how much packet loss there is on it.

Choosing a router
A router is the device that connects all your computers and network equipment to your Internet connection.  It is an often overlooked piece of the puzzle that can have a major impact on the success or failure of your voice-over-IP implementation.  There are many routers on the market, some are very cheap (less than $40) and others can cost you thousands of dollars.  There is nothing worse than putting a poor quality or underpowered router in your office which could cause an otherwise good VoIP installation to go bad.
Your router needs to be powerful enough to handle the number of phones you will have in your office and should also work flawlessly with voice-over-IP equipment.  A good place to start when deciding on your router is to speak with your voice-over-IP service provider. We also recommend checking to make sure that your router is compatible with voice-over-IP services.
The following is a list items which will help you to determine whether your router is right for voice-over-IP:
How many voice-over-IP phones will you be connecting to the router? The more phones you will be connecting, the more powerful the router needs to be. Don’t use a £40 router to run an office with 10 IP Telephones.
Will your voice-over-IP phones have their own dedicated Internet connection? If not, a router with a quality of service (QoS) setting to prioritize voice traffic over regular traffic is an absolute must. Without QoS you will encounter poor quality telephone calls regularly.
What other functions will the router need to perform? You might need your router to handle VPN connections, allow wifi (wireless) connections or perform other tasks.
Make sure you can bridge your router to your modem. Routers that are not bridged can cause problems with voice-over-IP installations.
Never use more than one router or nat gateway on the network at a time as this will cause problems for IP Telephones when they attempt to do NAT.
Make sure your router is compatible.
It is always best to get a recommendation from your voice-over-IP service provider as some routers are known to perform very poorly with VoIP phones.

Quality of service
Call quality is a function of your network and the public internet. Some delays and network congestion cannot be avoided due to information traveling over the public internet while other types can be avoided. Good network design is critical to a stable and reliable voice-over-IP implementation.
Quality of service (QoS) refers to the ability for your router to prioritize voice traffic (VoIP) differently than regular internet traffic on your network or the separation of voice traffic.  Voice over ip is a real-time protocol which means that if information is lost or delayed it will result in a noticeable drop in call quality or a complete loss of it. Symptoms of network congestion include garbled audio, dropped calls and echo.   When setting up voice-over-IP in your office there are three possible ways handle voice traffic. Some customers report perfectly good results without any quality of service (especially in a small 1-2 person office) and others report worse results with quality of service enabled on their router as some routers do a poor job of implementing this. Generally speaking however the best way to deliver reliable voice-over-IP service is through a dedicated internet connection that is only used by the voice-over-IP equipment rather than sharing the internet with computers. Below are the different methods of doing quality of service:

No QoS – Voice traffic and regular internet traffic in your office are sharing the same internet connection.  No prioritization of voice traffic over regular traffic is being performed and thus there is the high potential that voice quality could be degraded if there is insufficient bandwidth for both voice and regular traffic. Some customers experience very few problems using this method while others report a high frequency of poor quality calls, dropped calls and garbled voices. It all depends on how much network congestion your office has. Most internet connections are more likely to be upload bound which generally results in people not being able to hear you, because all of your upload bandwidth is being consumed by something on your network.

Router enabled QoS – Voice traffic and regular internet traffic in your office are sharing the same internet connection, but your router is able to distinguish between voice traffic and regular internet traffic and give the voice traffic a higher priority.  The problem with this method is that routers can only prioritize upload bandwidth which means your voice will be clear but the router cannot ensure that download bandwidth will be prioritized. If employees on your network are downloading often this will cause a noticeable drop in call quality but this method is better than no quality of service. Some internet providers can prioritize the download bandwidth using TOS or COS methods from their end which will create an end to end quality of service solution. Most customers find that even prioritising upload bandwidth for voice-over-IP offers a dramatic improvement in call quality because most internet connections are limited by their upload bandwidth and have lots of download bandwidth free.

Separated Traffic – Voice traffic and regular internet traffic are separated onto two different internet connections and networks. This is especially critical for larger offices with 5 or more employees.  Voice traffic is carried on one internet connection and data from computers is carried on the other connection. In this case no prioritization is required by your router because voice traffic has its own dedicated internet connection.  This is the best way to ensure clear voice communications and the method we generally recommend customers whenever possible.

The method you decide on largely depends on how much bandwidth you have, what you are using your internet connection for besides voice-over-IP and the level of call quality desired.  Many offices report perfectly good results without using any QoS, while others find that it makes a major difference in the quality of their calls.

Choosing VoIP phones and equipment
Before deploying voice-over-IP in your office you will need to decide how each employee will be connected to your voice-over-IP provider.  There are many choices on the market today.
Digital IP Telephones – These types of phones look just like regular multi-line business telephones except that they connect directly to your internet connection using a network cable.
Soft Phones – A soft phone is a software program running on your computer that looks and feels just like a real telephone.  This requires you to purchase a USB headset which connects to your desktop or laptop so you can make and receive calls.
Wifi Phones – A wifi phone looks and feels very much like a regular cell phone except that it connects to your wireless router in the office.
Analog Telephone Adapters (ATA) – An ATA is a small box which connects to your router and allows you to plug in regular analog telephones so they can work with voice-over-IP.  ATAs are generally low cost alternatives to digital office phones and are easy to take with you when you travel.
Battery backup and Power-over-Ethernet
With voice-over-IP and most office telephone systems you must consider what happens when the power goes out.  For some offices this can be a regular occurrence and for others it might happen with a very low frequency.  Once of the things you will need to decide is whether or not you will install a battery backup system.
Here are a few important terms your should know:
Power over Ethernet (PoE) – Is a technology that allows VoIP over ip telephones to be powered using regular network cables rather than power adapters which plug into the wall.  This has the advantage that you can power all the phones in your office from a single source and makes installing a battery backup unit much easier.
Uninterruptible Power Supply (UPS) – Is a device that powers your equipment when you lose power at the office.  The system has a built in battery which keeps your network devices operational when the power goes out.
The easiest way to protect your phone system from a power outage is to power all the phones using a Power-over-Ethernet switch that would normally be connected in the back room where your router and cable/DSL modem is located.  This has the advantage that all your phones are drawing power from a single source which you can backup using an uninterruptible power supply (UPS).  All you need to do is plug in your PoE switch, router, and DSL/cable modem into a sufficiently powerful UPS device so that when the power goes out all your phones remain up and running.