Issues with new SIP service ...

mrdom · Nov 1, 2018

Hi everyone:

We recently set up new SIP service with a SIP Provider, and for the first few weeks, all was well. This evening, I tried to make a call out, and zippo. I tried calling in, and the call would not go through. I spoke with tech support at our SIP Provider (MegaPath), and they said that there's nothing wrong on their end. When I check the asterisk/full log, we're getting flooded with these messages:

[pre]
[2018-11-01 20:37:28.079] NOTICE[2451] chan_sip.c: Registration from '<sip:218@75.128.XXX.XXX>' failed for '85.114.XXX.XXX:50001' - Wrong password
[2018-11-01 20:37:35.285] WARNING[2451] chan_sip.c: Timeout on 1319961118-542213201-369782102 on non-critical invite transaction.
[2018-11-01 20:37:43.012] WARNING[2451] chan_sip.c: Timeout on 1393699029-2066099480-711324631 on non-critical invite transaction.
[2018-11-01 20:37:43.021] WARNING[2451] chan_sip.c: Timeout on 1270337596-1721263048-431198333 on non-critical invite transaction.
[2018-11-01 20:37:51.491] WARNING[2451] chan_sip.c: Timeout on 1050722518-746364733-1591784192 on non-critical invite transaction.
[2018-11-01 20:38:06.830] WARNING[2451] chan_sip.c: Timeout on 833759871-1867472579-1639878891 on non-critical invite transaction.
[2018-11-01 20:38:10.349] WARNING[2451] chan_sip.c: Timeout on 6113511-1049189302-1476244350 on non-critical invite transaction.
[2018-11-01 20:38:22.607] WARNING[2451] chan_sip.c: Timeout on 1198195098-826918271-1922828333 on non-critical invite transaction.[/pre]

These errors are being posted to the log every 10-15 seconds. The only thing that changes is the 5-digit port number ... it's unique every time. This is the first time we're getting them ... haven't had them before.

At first I thought something happened with the secret, and I rechecked to make sure that the credentials given matched what we had in the PBX. Nothing awry there. This all started happening this afternoon. MegaPath noted that they lost our registration with their servers around 3pm this afternoon. I finally rebooted the UCx, and then I could get and make calls again, but these errors are persisting. I don't think it's anything on our end as nothing's changed since we first set things up. Anybody have an idea as to what's going on and who's side it's on (ours or theirs)? As of this writing, I'm still able to get and make calls.

Thanks for any wisdom you can shed!

theislandtech · Nov 2, 2018

Maybe something wrong on their end or with your register string

What is your router type? SIP ALG disabled?

ucxguy · Nov 2, 2018

Based on the log entries you posted, it is hard to say anything. The first entry is probably a SIP hacking attempt to register a SIP extension somewhere from Russia (hard to say when you replaced a portion of the address with XXX). The following entries are timeouts for INVITE transactions - my guess is it's also hacking, but in this case attempts to make calls instead of registering an extension.

The failure to communicate with the SIP trunk provider could be due to SIP hacking. Some time ago, SIP hacking scripts (commonly used by hackers from China, Palestine, Russia) used to send one request every few seconds. Recently, I've seen tens or even hundreds of SIP requests per second when the SIP port 5060 is left exposed to the Internet. Something like that can bring a slower server down to its knees, it eventually runs out of some resources (memory, file descriptors) and a restart of Asterisk (or reboot of the system) is needed to recover.

You should configure your router or your UCx to disallow such attacks. For example, you could
- configure your router's firewall to block incoming packets from unknown addresses
- enable the UCx firewall and allow incoming SIP packets only from known address(es) such as your SIP trunk provider
- change the SIP port used by UCx - the port 5060 is attacked all the time, so you could change it to something like 7060 or similar

mrdom · Nov 2, 2018

Thanks for the great posts islandtech and ucxguy. I did some more sleuthing, and after getting hostnames for these offending IP addresses, I discovered that they are remote servers in Germany!! I went into the router and blocked both IP addresses and checked the logs again. The registration attemps have stopped, We're stilll getting flooded with timeout invite transactions, however.

I'd like to try suggestions 1 and 3. How would I go about implementing #1? Would I have to put in a rule that only accepts packets from our SIP server? What might that rule look like in the firewall? If I change the port, is it as simple as changing it in the UCx, opening it on the router and closing port 5060?

I think what might have happened is that we were getting flooded with so many register requests that it eventually broke the registration with the SIP provider, and that caused us to go down. Thanks for the continued help!

theislandtech · Nov 3, 2018

Port forwarding is not needed unless you have remote extensions, or an remote office with only a digital gateway connecting back to the main office.

None of my sites have port forwarding, and I use a vpn for remote phones.

mrdom · Nov 3, 2018

Thanks islandtech. For kicks, I turned off the forwarding in our main router for port 5060 to our UCx box, and I could still make and receive calls. I think part of my problem is that I don't have enough wisdom with access rules in our router!

Here's a dumb question - without port 5060 forwarded to the UCx, how does the UCx route calls to the SIP provider, and how does the SIP provider route calls to the UCx? I was under the assumption that SIP calls came in on port 5060, and I had to open that port to allow the UCx (on our LAN) to communicate with our SIP provider (a WAN address with a SRV record). I guess I might understand outgoing calls as we have nothing blocked coming out of the LAN to the WAN, but from the SIP provider to us - how does the router know to route SIP traffic to the UCx without the port forwarded?

We have a Cisco router, and the default "block all" access rule is in effect:
[PRE]
ACTION----------SERVICE----------SOURCE----------INTERFACE----------SOURCE-----------DESTINATION-----------TIME
DENY ALL TRAFFIC WAN1 ANY ANY ANY ALWAYS [/pre]

If I'm reading this right, the router is blocking all traffic that's incoming into the router from the WAN, unless I open a port using port forwarding (we have some ports open for RDP access off campus) or I specify an ALLOW rule for a certain type of traffic. If this deny rule is truly in effect and I don't have any rules set directing traffic to the UCx, and I don't have port 5060 forwarded to the UCx, how are calls that originate from our SIP provider finding their way to our UCx? They must be somehow, as I can place a call with port 5060 closed/unforwarded. We have no remote users, so that's not an issue for us. Just trying to understand how this is all working. No complaints though - this little change has stopped all of the retransmits and rogue SIP authentication requests as well ... asterisk log is back to normal!!

We are using Dynamic DNS. I have our host name entered in under SIP settings. Does that have something to do with it?

Thanks for the continued wisdom!!

ucxguy · Nov 4, 2018

The reason is SPI (stateful packet inspection). Look up the terms "stateful packet inspection" or "stateful firewall" for more info.

theislandtech · Nov 4, 2018

Most routers allow outgoing connections
In your trunk configuration is the address to your SIP provider. The trunk will contact the provider and if successful will open the ports for a return connection. The registration sequence will keep the ports open.
I have many sites that use dynamic external IPs without the use of Dynamic DNS to provide a FQDN

Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

Issues with new SIP service ...

mrdom

MIS

theislandtech

Technical User

ucxguy

Programmer

mrdom

MIS

theislandtech

Technical User

mrdom

MIS

ucxguy

Programmer

theislandtech

Technical User

Similar threads

Part and Inventory Search

Sponsor