Community discussions

MikroTik App
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 8:51 am

Hello Forum
Beginning this past Saturday, 11-16, a few of my SIP customers on my network reported phones that were not working. It would not be the entire group of phones. Just one or two out of say, 4 or 6. Looking at the server details for each customer, I find that random VOIP phones were not registering anymore. Digging into it I find that the core router is registering multiple "unreplied" connections from the host routers and various UDP ports of their choosing. (please see firewall connections screenshot attached). I use Powercodes BMU and billing server with a Mikrotik 1100Ah router. Putting these through a reboot on a couple occasions tonite remixes which phones or ATA's register.
Having not experienced this before, I am looking to the forums for some troubleshooting ideas. Thank you in advance for your time.
sip connections.jpg
Firewall Export Screenshot
firewall.jpg.jpg
You do not have the required permissions to view the files attached to this post.
 
User avatar
janisk
MikroTik Support
MikroTik Support
Posts: 6263
Joined: Tue Feb 14, 2006 9:46 am
Location: Riga, Latvia

Re: Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 11:19 am

check in '/ip firewall service-port' and see if sip is enabled, you can try to disable it and see if behaviour you are observing will change.
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Re: Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 3:44 pm

Hello Janisk
Thanks for responding.
Yes, searching the forums on SIP issues I found posts that mentioned turning off the NAT helper SIP function. I have already made that settings adjustment earlier with no discernible change.
The random nature of the phone re-regs prompted me to look further into the connection tracking. Doing so, I found thousands of GRE connections made from 6 external addresses on the source address.
I put in a filter to drop the GRE traffic
add chain=input in-interface=wan protocol=gre action drop
This is killing a few pptp connections I have but will allow me to see what occurs with these GRE connections. Even so, that does not account for the random SIP registration behavior?
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 4:55 pm

What happens if you add connection-state=new for both the input and forward chains? That is what I'm doing. I too have the SIP helper turned off.
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Re: Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 5:44 pm

What happens if you add connection-state=new for both the input and forward chains? That is what I'm doing. I too have the SIP helper turned off.
No solution with that addition. I turned the NAT helper on again just to check that config option too. Did that addition resolve SIP reg issues for you?

Still digging
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 7:26 pm

I turned the NAT helper on again just to check that config option too. Did that addition resolve SIP reg issues for you? Still digging
I don't use the MikroTik NAT helper. I have a FreePBX distro and also some phones behind a MikroTik RB2011* running ROS v6.6. The PBX has a SIP trunk to voip.ms and some of the phones are SIP'ing to voip.ms separately from the PBX. The phones are Snom's so I have nat checked on them. Thus they keep a UDP port open by sending out a packet every 120 seconds or so. FreePBX does the same.

However, if the connection goes down (or I kill a UDP session manually) the phones loose registration for several minutes (I've not actually timed) it. This may be your problem. My firewall rules look something like this. Notice I'm not opening ports because the PBX and phones open one and keep it open.

ros code

#Router and internal network protection, no internal servers, LAN is friendly
/ip firewall filter
add chain=input   action=drop   connection-state=invalid                            comment="Disallow weird packets" 
add chain=input   action=accept connection-state=new         in-interface=ether-LAN comment="Allow LAN access to the router itself"
add chain=input   action=accept connection-state=established                        comment=" ^^ that originated from LAN"
add chain=input   action=accept connection-state=related                            comment=" ^^ that originated from LAN"
add chain=input   action=accept protocol=icmp                                       comment="Allow ping ICMP from anywhere"
add chain=input   action=drop                                                       comment="Disallow anything else" 
add chain=forward action=drop   connection-state=invalid                            comment="Disallow weird packets" 
add chain=forward action=accept connection-state=new         in-interface=ether-LAN comment="Allow LAN access to move through the router"
add chain=forward action=accept connection-state=established                        comment=" ^^ that originated from LAN"
add chain=forward action=accept connection-state=related                            comment=" ^^ that originated from LAN"
add chain=forward action=drop                                                       comment="Disallow anything else"
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Re: Multiple Unreplied Connections on SIP Traffic

Tue Nov 19, 2013 11:22 pm

Thanks pcunite for the filter code.
Yes, I have the same filters applied. Here is my ROS filter with a few of the IP's I am trying to get rid of:
/ip firewall filter
add chain=input connection-state=established
add chain=input connection-state=related
add chain=input connection-state=new
add chain=forward connection-state=established
add chain=forward connection-state=new
add chain=forward connection-state=related
add action=drop chain=input connection-state=invalid
add action=drop chain=output out-interface=TH protocol=gre src-address=108.66.160.187
add action=drop chain=output out-interface=TH protocol=gre src-address=107.223.149.47
add action=drop chain=output out-interface=TH protocol=gre src-address=69.29.90.86
add action=drop chain=output out-interface=TH protocol=gre src-address=72.16.15.213
add action=drop chain=output out-interface=TH protocol=gre src-address=70.182.28.60
add action=drop chain=output out-interface=TH protocol=gre src-address=70.182.28.60
add action=drop chain=output out-interface=TH protocol=gre src-address=70.166.130.156
add action=jump chain=input comment="Drop SSH brute force attacks" dst-port=22 jump-target="Brute Force SSH" protocol=tcp
add action=drop chain="Brute Force SSH" dst-port=22 protocol=tcp src-address-list=ssh_blacklist
add action=add-src-to-address-list address-list=ssh_blacklist address-list-timeout=12h chain="Brute Force SSH" \
    connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage5
add action=add-src-to-address-list address-list=ssh_stage5 address-list-timeout=5s chain="Brute Force SSH" \
    connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage4
add action=add-src-to-address-list address-list=ssh_stage4 address-list-timeout=5s chain="Brute Force SSH" \
    connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage3
add action=add-src-to-address-list address-list=ssh_stage3 address-list-timeout=5s chain="Brute Force SSH" \
    connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage2
add action=add-src-to-address-list address-list=ssh_stage2 address-list-timeout=5s chain="Brute Force SSH" \
    connection-state=new dst-port=22 protocol=tcp src-address-list=ssh_stage1
add action=add-src-to-address-list address-list=ssh_stage1 address-list-timeout=5s chain="Brute Force SSH" \
    connection-state=new dst-port=22 protocol=tcp src-address=!66.119.x.xxx
add chain=output comment="Block FTP Brute Force" content="530 Login incorrect" dst-limit=1/1m,4,dst-address/1m protocol=\
    tcp
add action=add-dst-to-address-list address-list=ftp_blacklist address-list-timeout=1d chain=output content=\
    "530 Login incorrect" protocol=tcp
add action=drop chain=input dst-port=21 protocol=tcp src-address-list=ftp_blacklist
I am sure the GRE connections and SIP issues are related but I cannot put it together at this point. I am calling on a fellow ISP's admin guru to lend a hand. Gotta know when to pull in some different ideas.
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Re: Multiple Unreplied Connections on SIP Traffic

Wed Nov 20, 2013 9:32 am

Here is an update that may prove useful.
The torch image I have posted shows all SIP customers and their related source and destination info. I color coordinated the accounts so you can see how they are connecting.
As you can see in blue, two host phones connect while one does not. Same applied to red and even one customer with just an ATA is failing to register. Two others, gold and purple, are linked up fine.
Note the source NATed outbound IP of the no-reg's. They stay local and have no transmit traffic while those that do register, NAT appropriately and function.
This pattern will change too. Gold will drop one while red will gain one for example.
torch.jpg
I am still digging on how to proceed from here but hope this behavior trips an idea from someone that has seen the issue before.
You do not have the required permissions to view the files attached to this post.
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1345
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: Multiple Unreplied Connections on SIP Traffic

Wed Nov 20, 2013 3:20 pm

Here is an update that may prove useful. Note the source NAT'ed outbound IP of the no-reg's. They stay local and have no transmit traffic while those that do register, NAT appropriately and function.
Excellent, yes this helps and will narrow down the issue for you. What does your IP / Firewall / Nat rules look like?
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Re: Multiple Unreplied Connections on SIP Traffic

Wed Nov 20, 2013 4:07 pm

Morning pcunite

It is just a straight masquerade. Nothing special happening at all.
 
JJCinAZ
Member
Member
Posts: 475
Joined: Fri Oct 22, 2004 8:03 am
Location: Tucson, AZ

Re: Multiple Unreplied Connections on SIP Traffic

Wed Nov 20, 2013 4:29 pm

You should enable the display of the reply-dst and reply-src addresses in the Connections list. That might show you something interesting.
 
ulink
Member Candidate
Member Candidate
Topic Author
Posts: 128
Joined: Fri Mar 05, 2010 5:07 am

Re: Multiple Unreplied Connections on SIP Traffic

Wed Nov 20, 2013 6:04 pm

You should enable the display of the reply-dst and reply-src addresses in the Connections list. That might show you something interesting.
trackreply.jpg
Source NATing is just not happening correctly. The SIP server does not want to associate with the LAN IP. Now, how to kick it into correctly operating like it has for almost 2 years?
I have skimmed the ROS release notes looking for signs of hope. Would ROS upgrade be necessary? I am running v5.19
You do not have the required permissions to view the files attached to this post.
 
JJCinAZ
Member
Member
Posts: 475
Joined: Fri Oct 22, 2004 8:03 am
Location: Tucson, AZ

Re: Multiple Unreplied Connections on SIP Traffic

Wed Nov 20, 2013 6:35 pm

I can't see it in your screen shot, but there could be a couple of things. First, it looks like you still have the sip nat helper enabled and if so, I recommend disabling it. Second, could your public IP address be changing such that the sip server is seeing you come from different addresses. With he masq nat, the source ip comes from the preferred source of the route used from the ip route table. If that is changing or there are multiple possible routes then maybe multiple IPs are being used to source.

Who is online

Users browsing this forum: Bing [Bot] and 57 guests