Community discussions

MikroTik App
 
marwooj
newbie
Topic Author
Posts: 35
Joined: Mon Nov 06, 2017 10:44 am

VoIP / SIP big problems

Thu Feb 15, 2018 4:33 pm

I do have internal PBX that is providing land lines and some internal extensions for remote offices.
The problem is that I often have SIP registration problem to my remote SIP provider. I do see it is trying to register but packet are lost just after prerouting.

prerouting: in:bridge1 out:(none), src-mac b0:b3:2b:06:06:1b, proto UDP, 192.168.1.23:5060->89.209.199.9:5060, NAT 192.168.1.23:5060->(89.209.199.9:5060->192.168.1.23:5060), len 425

Is this common behavior for internal PBX to source connection to the same port that it is starting from sourceip:5060 to external_provider_ip:5060?

What should NAT rules look like?
0    ;;; defconf: masquerade
      chain=srcnat action=masquerade out-interface-list=WAN ipsec-policy=out,none 
 1    chain=srcnat action=masquerade out-interface=ether1 
 2    chain=dstnat action=dst-nat to-addresses=192.168.1.23 to-ports=5522 protocol=udp dst-port=5522 log=no log-prefix="" 
 3    chain=dstnat action=dst-nat to-addresses=192.168.1.23 to-ports=5060 protocol=udp dst-port=5060 log=no log-prefix="SIP" 
 4    chain=dstnat action=dst-nat to-addresses=192.168.1.23 to-ports=5061 protocol=udp dst-port=5061 log=no log-prefix="SIP" 
 5    chain=dstnat action=dst-nat to-addresses=192.168.1.23 to-ports=8100-8300 protocol=udp dst-port=8100-8300 log=no log-prefix="" 
 6 X  ;;; 10000-20000
      chain=dstnat action=dst-nat to-addresses=192.168.1.23 to-ports=10000-20000 protocol=udp dst-port=10000-20000 log=no

PBX logs:
[2017-11-27][13:32:46.814] REGISTER 12 headers, 0 lines
[2017-11-27][13:32:46.817] .--------------- --- -- -
[2017-11-27][13:32:46.820] | SIP Reliably Transmitting (NAT) to 89.209.199.9:5060
[2017-11-27][13:32:46.828] |----------- --- -- -
[2017-11-27][13:32:46.831] | REGISTER sip:89.209.199.9 SIP/2.0
[2017-11-27][13:32:46.834] | Via: SIP/2.0/UDP 192.168.1.23:5060;
[2017-11-27][13:32:46.856] | CSeq: 106 REGISTER
[2017-11-27][13:32:46.897] | Event: registration
[2017-11-27][13:32:46.901] | Content-Length: 0
[2017-11-27][13:32:46.910] `------ --- -- -
[2017-11-27][13:32:47.808] .--------------- --- -- -
[2017-11-27][13:32:48.052] | SIP Retransmitting #1 (NAT) to 89.209.199.9:5060
[2017-11-27][13:32:48.056] |----------- --- -- -
[2017-11-27][13:32:48.060] | REGISTER sip:89.209.199.9 SIP/2.0
[2017-11-27][13:32:48.064] | Via: SIP/2.0/UDP 192.168.1.23:5060;
[2017-11-27][13:32:48.081] | CSeq: 106 REGISTER
[2017-11-27][13:32:48.102] | Event: registration
[2017-11-27][13:32:48.109] | Content-Length: 0
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1109
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: VoIP / SIP big problems

Thu Feb 15, 2018 5:38 pm

You shouldn't need to do anything special, no special firewall rules, no special nat rules, for things to work. Do turn off MikroTik's SIP ALG feature (ip / firewall / service ports, then disable SIP).

Your PBX should have some settings for NAT which will keep an open connection over UDP to your provider.
Last edited by pcunite on Fri Feb 16, 2018 12:17 am, edited 1 time in total.
 
marwooj
newbie
Topic Author
Posts: 35
Joined: Mon Nov 06, 2017 10:44 am

Re: VoIP / SIP big problems

Thu Feb 15, 2018 7:06 pm

So I assume that my NAT rules are fine?
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1724
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: VoIP / SIP big problems  [SOLVED]

Thu Feb 15, 2018 7:52 pm

Don't see any interfaces on your dst nat rules, add your WAN interface as "in" interface on these rules
MTCNA, MTCTCE, MTCRE & MTCINE
 
sindy
Forum Guru
Forum Guru
Posts: 5509
Joined: Mon Dec 04, 2017 9:19 pm

Re: VoIP / SIP big problems

Thu Feb 15, 2018 8:50 pm

You shouldn't need to do anything special, no special firewall rules, no special nat rules, for things to work. Do turn of MikroTik's SIP ALG feature (ip / firewall / service ports, then disable SIP).
Your PBX should have some settings for NAT which will keep an open connection over UDP to your provider.
That's not always that simple. While you're right that a SIP phone should not have to do anything special, the ALG should not be necessary, and the VoIP provider's exchange should still be able to deal with the fact that the SIP phone is behind a NAT, this is unfortunately not always the case.

But the behaviour of a PBX mimicking a registering client towards the provider's exchange should not differ much from that of a SIP phone. So I would suspect that your registrations sometimes fail because your static dst-nat rules collide in some way with the reverse mappings of the connection trackings created by masquerade (which is a special variant of src-nat).

So I would first try to configure the dst-nat rule for 5060 so that it works for any source IP address except the one of the provider's exchange (by adding "src-address=!providers.exchange.ip.address" to the rule) if you need those rules for the phones which connect to your PBX. If you don't, I'd simply disable all the dstnat rules to see how the registration works without them.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
pcunite
Forum Guru
Forum Guru
Posts: 1109
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: VoIP / SIP big problems

Fri Feb 16, 2018 12:19 am

So I assume that my NAT rules are fine?

If you want/need NAT rules, they should look like this. First a sample firewall script setup to allow NAT. Then a sample NAT rule.
/ip firewall filter
add chain=input action=accept connection-state=established,related comment="Accept established related"
add chain=input action=accept in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=input action=drop comment="Drop all other input"
add chain=forward action=accept connection-state=established,related comment="Accept established related"
add chain=forward action=accept connection-state=new in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=forward action=accept connection-nat-state=dstnat comment="Allow Port forwards"
add chain=forward action=drop comment="Drop all other forward"

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether-WAN comment="Default masq"
add chain=dstnat action=dst-nat in-interface=ether-WAN protocol=tcp to-addresses=1.2.3.4 dst-port=123 to-ports=123 comment="Sample Port Forward"
 
sindy
Forum Guru
Forum Guru
Posts: 5509
Joined: Mon Dec 04, 2017 9:19 pm

Re: VoIP / SIP big problems

Sat Feb 17, 2018 12:00 am

Don't see any interfaces on your dst nat rules, add your WAN interface as "in" interface on these rules
Oh my... that's really the problem here, I just got pushed off-track by
The problem is that I often have SIP registration problem to my remote SIP provider.
Without @CZFan's suggested change, the dst-nat rule not only redirects packets coming from outside towards port 5060 of Mikrotik's public IP to your PBX, but it also redirects packets which your PBX is sending to port 5060 of VoIP provider's equipment back to the PBX. So I wonder how it is possible that the registration doesn't fail always.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
marwooj
newbie
Topic Author
Posts: 35
Joined: Mon Nov 06, 2017 10:44 am

Re: VoIP / SIP big problems

Sun Feb 18, 2018 2:42 pm

Don't see any interfaces on your dst nat rules, add your WAN interface as "in" interface on these rules
Added in-interface=ether1 on NAT, hope it saves my life.

Should that one:
https://wiki.mikrotik.com/wiki/Manual:I ... forwarding

be updated?
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1724
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: VoIP / SIP big problems

Sun Feb 18, 2018 4:13 pm

Don't see any interfaces on your dst nat rules, add your WAN interface as "in" interface on these rules
...
Should that one:
https://wiki.mikrotik.com/wiki/Manual:I ... forwarding

be updated?
If I understand you correctly, then it is the same thing, except they are using the IP Address of the WANT interface, instead of interface itself, you can do the same thing if you have a "static" WAN IP Address
MTCNA, MTCTCE, MTCRE & MTCINE
 
sindy
Forum Guru
Forum Guru
Posts: 5509
Joined: Mon Dec 04, 2017 9:19 pm

Re: VoIP / SIP big problems

Sun Feb 18, 2018 4:28 pm

If I understand you correctly, then it is the same thing, except they are using the IP Address of the WAN interface
Unfortunately, they don't:
/ip firewall nat add chain=dstnat \
protocol=tcp dst-port=1234 \
action=dst-nat to-address=192.168.1.1 to-port=1234
The to-address defines the new value, dst-address would match the original one but it is missing. So the rule really matches packets coming in via any interface and to any destination address. I'm afraid nobody thought about peer2peer protocol which listens on port X but also sends its requests to the same port X when writing the documentation.

For most use cases where usual client/server protocols are involved this omission doesn't cause any issues. And the less conditions to evaluate, the faster the rule processing. So if I'd be modifying the documentation, I'd add this as a warning but wouldn't put the additional condition into the example.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1724
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: VoIP / SIP big problems

Sun Feb 18, 2018 4:55 pm

If I understand you correctly, then it is the same thing, except they are using the IP Address of the WAN interface
Unfortunately, they don't:
/ip firewall nat add chain=dstnat \
protocol=tcp dst-port=1234 \
action=dst-nat to-address=192.168.1.1 to-port=1234
The to-address defines the new value, dst-address would match the original one but it is missing. So the rule really matches packets coming in via any interface and to any destination address. I'm afraid nobody thought about peer2peer protocol which listens on port X but also sends its requests to the same port X when writing the documentation.

For most use cases where usual client/server protocols are involved this omission doesn't cause any issues. And the less conditions to evaluate, the faster the rule processing. So if I'd be modifying the documentation, I'd add this as a warning but wouldn't put the additional condition into the example.
I was referring to the rule below on wiki ;-)
/ip firewall nat
add chain=dstnat dst-address=10.5.8.200 dst-port=21 protocol=tcp action=dst-nat to-addresses=192.168.0.109
MTCNA, MTCTCE, MTCRE & MTCINE
 
sindy
Forum Guru
Forum Guru
Posts: 5509
Joined: Mon Dec 04, 2017 9:19 pm

Re: VoIP / SIP big problems

Sun Feb 18, 2018 5:38 pm


I was referring to the rule below on wiki ;-)
/ip firewall nat
add chain=dstnat dst-address=10.5.8.200 dst-port=21 protocol=tcp action=dst-nat to-addresses=192.168.0.109
:-) and that's the point. The chapter to which the OP has referred to is "5.2.2 Port mapping/forwarding" and I've quoted the rule from there.
The rule you refer to belongs already to the next chapter, "5.2.3 Port forwarding to internal FTP server", so why should an I-want-it-right-now guy not currently interested in FTP even read it?

This is an example of why I say that I prefer that people understand what they do rather than just copy-paste. But as my father used to say - a communicated experience is none of an experience. So everyone has to crash his your own mouth to take better care next time.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
marwooj
newbie
Topic Author
Posts: 35
Joined: Mon Nov 06, 2017 10:44 am

Re: VoIP / SIP big problems

Mon Feb 19, 2018 9:04 pm

how about this one for RTP, is it ok?:
chain=dstnat action=dst-nat to-addresses=192.168.1.23 to-ports=8100-8300 protocol=udp in-interface=ether1 dst-port=8100-8300 log=no log-prefix="RTP"
 
User avatar
CZFan
Forum Guru
Forum Guru
Posts: 1724
Joined: Sun Oct 09, 2016 8:25 pm
Location: South Africa, Randburg
Contact:

Re: VoIP / SIP big problems

Mon Feb 19, 2018 9:17 pm

Take out the to ports=8100-8300, you are not translating port numbers to different port numbers
MTCNA, MTCTCE, MTCRE & MTCINE
 
marwooj
newbie
Topic Author
Posts: 35
Joined: Mon Nov 06, 2017 10:44 am

Re: VoIP / SIP big problems

Mon Feb 19, 2018 9:43 pm

Hi, does the order of rules matters?
 
sindy
Forum Guru
Forum Guru
Posts: 5509
Joined: Mon Dec 04, 2017 9:19 pm

Re: VoIP / SIP big problems

Mon Feb 19, 2018 9:46 pm

Hi, does the order of rules matters?
It does for rules in the same chain which may match the same packets.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
marwooj
newbie
Topic Author
Posts: 35
Joined: Mon Nov 06, 2017 10:44 am

Re: VoIP / SIP big problems

Mon Feb 19, 2018 9:51 pm

The "to-ports=" is also taken from documentation.
 
sindy
Forum Guru
Forum Guru
Posts: 5509
Joined: Mon Dec 04, 2017 9:19 pm

Re: VoIP / SIP big problems

Mon Feb 19, 2018 10:06 pm

The "to-ports=" is also taken from documentation.
That's true, but it is all about "understand what you do". You cannot blindly paste examples and only edit values to fit to your case.

Basically, each firewall rule consists of a list of values of packet properties which the packet must have so that the rule would match it (such as dst-address, protocol, dst-port etc.), an action, and a list of parameters for that action if it requires them.

For dst-nat and src-nat actions, you must provide at least one of (to-addresses, to-ports) so that the action would make sense, but if you provide a range for either of them, the new value of that property is assigned, let's say randomly, from that range regardless the original value.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.

Who is online

Users browsing this forum: atcychew, dtrdimi, Google [Bot] and 72 guests