v15 with Mikrotik Router

[craigreilly]

I was on v14 until today. We didn't seem to be having issues on v14 - atleast nobody mentioned anything to me. When I ran the firewall checker on v15 - some RTP ports failed as "full cone test fail" and others "not reachable". The strange part about this is that the ports change on every test. This time, ports 9002, 9003, 9004 might fail and the next 9025,9026,9027,9030,9040, etc.
Also, voice in and out is working fine on the Flowroute trunk - as well as remote extensions.
SIP service is disabled on the Mikrotik, RTP Ports 9000-9255 on UDP forwarded. Also outbound NAT is setup so all traffic from PBX is seen as the Static Public IP setup in 3cx.

Any one with experience with Mikrotik know what to check.

 

[dab]

For me it's working fine.
Before Firewalltest I have to remove a src-list filter which in the normal case only my voip provider admits to talk.

 

[complex1]

Hi,

I'm using several RB2011UiAS-2HnD all running on F/W v6.38.1 and no problems with firewall checker at all.

This are the NAT filter rules I am using:

[admin@MikroTik] /ip firewall nat> print
Flags: X - disabled, I - invalid, D - dynamic
 0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface=ether1
 1    ;;; 3CX Phone System
      chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=tcp in-interface=ether1 dst-port=5060 log=no log-prefix=""
 2    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=udp in-interface=ether1 dst-port=5060 log=no log-prefix=""
 3    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=udp in-interface=ether1 dst-port=9000-9255 log=no log-prefix=""
 4    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=udp in-interface=ether1 dst-port=9256-9499 log=no log-prefix=""
 5    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=tcp in-interface=ether1 dst-port=5090 log=no log-prefix=""
 6    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=udp in-interface=ether1 dst-port=5090 log=no log-prefix=""
 7    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=tcp in-interface=ether1 dst-port=5000 log=no log-prefix=""
 8    chain=dstnat action=dst-nat to-addresses=IP-PBX protocol=tcp in-interface=ether1 dst-port=5001 log=no log-prefix=""

Hope this helps.

BTW: All systems are running on Windows 10, not on Debian.

 

[craigreilly]

Here is mine. The only difference I see is I have a dst-address of my PBX Public IP Address, and my outbound rule is slightly different. Running Server 2012. Mikrotik CCR-1009.
I did try moving the 9000 ports to its own rule - but no difference.

chain=dstnat action=dst-nat to-addresses=192.168.3.230 protocol=udp
      dst-address=Public-IP dst-port=5060,9000-9500,5090 log=no
      log-prefix="SIP"

chain=dstnat action=dst-nat to-addresses=192.168.3.230 protocol=tcp
      dst-address=Public-IP dst-port=5060,5061,5090,80,443 log=no
      log-prefix=""

chain=srcnat action=src-nat to-addresses=Public-IP
      src-address=192.168.3.230 out-interface=WAN log=no log-prefix=""

testing ports [9000..9255]... failed

• testing port 9000... done
• testing port 9001... done
• testing port 9002... done
• testing port 9003... not reachable
• testing port 9004... done
• testing port 9005... not reachable
• testing port 9006... done
• testing port 9007... not reachable
• testing port 9008... not reachable
• testing port 9009... done
• testing port 9010... done
• testing port 9011... done
• testing port 9012... done
• testing port 9013... done
• testing port 9014... not reachable
• testing port 9015... done
• testing port 9016... not reachable
• testing port 9017... done
• testing port 9018... done
• testing port 9019... done
• testing port 9020... done
• testing port 9021... done
• testing port 9022... done
• testing port 9023... done
• testing port 9024... done
• testing port 9025... done
• testing port 9026... done
• testing port 9027... not reachable
• testing port 9028... done
• testing port 9029... done
• testing port 9030... not reachable
• testing port 9031... not reachable
• testing port 9032... done
• testing port 9033... done
• testing port 9034... not reachable
• testing port 9035... not reachable
• testing port 9036... not reachable
• testing port 9037... done
• testing port 9038... done
• testing port 9039... done
• testing port 9040... done
• testing port 9041... done
• testing port 9042... done
• testing port 9043... not reachable
• testing port 9044... done
• testing port 9045... not reachable
• testing port 9046... not reachable
• testing port 9047... done
• testing port 9048... done
• testing port 9049... done
• testing port 9050... done
• testing port 9051... not reachable
• testing port 9052... not reachable
• testing port 9053... done
• testing port 9054... done
• testing port 9055... not reachable
• testing port 9056... done
• testing port 9057... done
• testing port 9058... done
• testing port 9059... done
• testing port 9060... done
• testing port 9061... done
• testing port 9062... done
• testing port 9063... done
• testing port 9064... not reachable
• testing port 9065... done
• testing port 9066... done
• testing port 9067... done
• testing port 9068... done
• testing port 9069... done
• testing port 9070... done
• testing port 9071... done
• testing port 9072... not reachable
• testing port 9073... done

 

[Sopock]

dst-port=5060,9000-9500,5090

Each in separate line?

 

[complex1]

Hi,

I can’t use dst-address because I have a Dynamic WAN address.
What if you temporarily disable all your rules and add the rules I’m using, just for test?
Is that possible?

 

[craigreilly]

We are about 24/7 - never know when folks will log in. So, I can not disable other rules. But I have moved RTP to its own line with no change.
Also sent you a PM with a wireshark on a failed port... if you have time. Thanks.

 

[craigreilly]

Each in separate line?

As I mentioned: "I did try moving the 9000 ports to its own rule - but no difference."

The system seems to work fine and worked fine on v14. I'm just trying to figure this out... just in case. Mikrotik is on 6.38.1

 

[eagle2]

What version is router firmware, you are running.

I have over 100 3CX installations, all using various Mikrotik routers, including cloud solutions. I have used various firmware versions, latest 6.37.4 (bugfix). See also: https://www.3cx.com/community/threa...t-working-remotely-with-3cx-v14sp3-pbx.46768/ -- it describes another issue, related to MSS size of TCP packets, but there is a solution for Mikrotik routers how to fix.

I really doubt the problem is related to Mikrotik router itself, your configurations should be working. Restart the router, if you haven't. Do you have another router in front of Mikrotik (from Internet provider, etc.)?

 

[eagle2]

I've made some tests on several on my 3CX installations -- yes version 15 SP4 firewall checker reports an error, nevertheless all these PBXs are in production and are working normally. I guess this is a kind a bug in 3CX version 15, as in the same time, on the same cloud router,version 14 PBXs firewall checker passes OK.

 

[datamerge]

I can also attest to using 3CX behind Mikrotik routers with no issues. Interesting #eagle2 you had issues with Mikrotik. I had a client on v15 on an Audiocodes router and I had the same issues with various random ports failing. I put it down to an undersized nat table. When I replaced the router with a Mikrotik RB750G3 on 11.37.1 the test passed first time.
#CraigReilly. I use the ruleset exactly the way you do on all my Mikrotiks. That is perfectly valid. I can't think why you would have an issue. I am wondering whether it is the CCR. You might want to check the CPU usage on the cores as CCRs are known to have some issues with multithreading and you may have a core getting bound up.

Just a guess.

 

[craigreilly]

I tried setting the MSS to the lower value for inbound and outbound TCP traffic. No dice.
I am on latest release 6.38.1
Its Monday - bound to be a lot of phone calls - lets see how 3cx v15 handles things.

 

[craigreilly]

I've made some tests on several on my 3CX installations -- yes version 15 SP4 firewall checker reports an error, nevertheless all these PBXs are in production and are working normally. I guess this is a kind a bug in 3CX version 15, as in the same time, on the same cloud router,version 14 PBXs firewall checker passes OK.

I missed this first time around today. thanks for reporting back. I feel better about my install now.

 

[datamerge]

You don't use any connection rate throttling do you?

I use this for TCP limits, but if you had a UDP rule like this you would get the same issue. The following rules are in my router to limit the number of connections to a given IP address to 10/s initially then 5/sec after the first second. I put this in because of that abomination called Windows 10 update.

add action=accept chain=forward connection-state=new dst-limit=5,10,dst-address/1m40s out-interface=ether1-Internet protocol=tcp
add action=drop chain=forward connection-state=new out-interface=ether1-Internet protocol=tcp

 

[craigreilly]

no rate limiting...
-some filter rules to prevent hacking attempts - which I turned off during testing .
-a mangle rule to set DSCP.

 

[craigreilly]

• testing port 9025... done
• testing port 9026... full cone test failed
• testing port 9027... full cone test failed
• testing port 9028... full cone test failed
• testing port 9029... done

on 6.38.5 getting just 3 these fail. But next test, will be other ports.

However, an upgrade on Mikrotik to 6.39.1 and no failed ports - with ZERO changes to the Configuration.