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?
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.
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.
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.
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
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.
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.
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”
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.
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.