I’m trying to resolve some NAT problems with voip. (One way audio only)
I have currently 2 scenario.
The first is this:
SIP Provider Server → Mikrotik CCR as Gateway → SIP PBX Server (asterisk) → Customer Mikrotik Routerboard → SIP devices (gigaset and grandstream)
The second scenario is:
SIP provider server → Mikrotik CCR as Gateway → Customer Mikrotik Routerboard → SIP PBX Server (asterisk) , on the same subnet some SIP devices
→ Another Customer Mikrotik Routerboard → SIP devices
For the moment I forced all my devices that comes from natted network to negotiate on a different SIP port for example
Gigaset1 port → 5060
Gigaset2 port → 5061
Gigaset3 port → 5062
I don’t know if this is right to do
Then I also forced the devices to negotiate the same RTP port range of the asterisk PBX. 10000-20000 Also for this I don’t know if I’m right.
Then I created for the scenario 2 some firewall and nat rules on the RB with the PBX:
Actually I don’t have any rules for the first scenario.
As I said I don’t know if all this is right and if I have to implement other to make things work well, actually seems all working but I’m not sure if only a coincidence or not.
This isn’t usually necessary for dynamic (registered endpoint) connections that come from behind the firewall reaching out to a server upstream from the firewall. You’ll also need to make sure that the SIP keepalive interfval is shorter than the firewall’s connection tracking idle timeout value for UDP sockets.
Now, if there is an un-registered SIP connection - meaning that two nodes are just configured to accept calls from each other, but neither one must register to the other as an endpoint - then you do need to at least map a dedicated SIP port for such a relationship because it may be hours, days, weeks, etc - some arbitrarily long time between any packets being sent because SIP packets are only sent whenever a call is made between these devices.
One way audio is one possible symptom of the SIP helper messing with things.
This is because the helper can actually make changes to the values of the messages contained in the SIP / SDP packets.
As for connection tracking timeout, go into IP Firewall Connections, and click the “Tracking” button.
I have to disable SIP Helper also in the scenario 2 where there are some devices in the same PBX subnet and some that connects from other routerboards?
I was testing also ipip tunnel and eoip tunnel. But I cannot make them work. The two routerboards ping themselves but I cannot ping devices under.
In general, I wouldn’t recommend the EoIP method - especially not a giant bridged segment (all sites using 192.168.2.0/24) because bridging will introduce all kind of avenues for headaches - broadcast storms, network loops, etc - it’s better to route across tunnels in your case.
However, I wouldn’t recommend using them at all - it shouldn’t be necessary.
In general, I’ve found that SIP always works better through Mikrotiks when the Mikrotiks have SIP helper disabled. (nothing against Mikrotik - this helper is most likely the one written by the Linux kernel / netfilters teams, and not Mikrotik themselves)
Now this does assume one thing - that the upstream SIP server knows how to detect NAT and work around it properly.
In the scenario where you have an on-site PBX, whether or not you need the static pinholes/address mappings etc depends on whether the PBX registers as an endpoint with the main PBX, or if the two hosts just accept SIP calls from each other. In either case, I would suggest that the on-site PBX be configured to signal the phones to send all RTP to the on-site PBX except for extension-to-extension calls between two phones at the same site. So external calls should always use the on-site PBX as a media proxy so that all RTP is between the site PBX and the host PBX as far as the firewall is concerned.
I’ve seen some installations that require specifically mapped RTP ranges for each device, but this is almost always a workaround for an over-zealous firewall. NAT should “just work” for the RTP streams because once the on-site device starts sending its RTP stream, even with a dynamically-chosen source port (e.g. 23456), the RTP packets from the remote end of the call should arrive with dst port = 23456. (If they don’t, then it’s most likely because the firewall chose a different port than the SIP messages specified, and the remote server does not have nat traversal configured properly)
So obviously, things are going to be much more under your control if your main PBX also forces all media streams to be routed via the server and not directly endpoint-to-endpoint.
Actually changed IP addressing of one site so I have:
RB1:
WAN 172.18.3.40
subnet 192.168.2.0/24
RB2
WAN 172.18.3.44
subnet 192.168.3.0/24
Now eoip tunnel is not a giant bridge, and I have no more to deal with dhcp, 2 gateways eccetera.
Seems all working, if you look to this screen now all extensions arrives with port 5060 and so I dont’have to deal with NAT (The two that comes with other ports don’t have a mikrotik to create eoip tunnel)
Actually it seems the only way that works for me, I have also disabled sip helpers on all routerboards involved.
About the UDP timeout on connection tracking, is better to change the timeout on RB or change keepalive on PBX? In the case of PBX what is the exact value to change?
The keepalive thing is only going to be a factor if you’re using a stateful firewall between the devices. So over your vpn tunnels, if there are no filter rules applied and no NAT applied, then it’s not a factor.
As for which knob to turn if you do need to tweak this - it depends. If the SIP session keepalive time is something long like an hour, then that needs to be reduced because holding UDP sockets open for an hour of inactivity could lead to issues, especially since your installations will be making use of many relatively-short-duration UDP streams, and you don’t want to run out of port numbers due to lots of inactive ports being held open for no reason. Tweaking the session heartbeat is probably best done on the server.
Increasing the timeout value in the routers would make sense if you just need to add a few minutes.
I just have another question, in my current setup what I have to set in “NAT mode” in freepbx extensions? Actually I have “Yes, force Rport, Comedia” but I’m not sure it is right as now.
This kind of setting is a way for the SIP endpoint (or PBX in this case) to participate in working around NAT by itself. When you use this feature, you’re informing the device that it’s behind NAT, and telling it what public IP address it will appear to be on the outside world, and possibly a port number that is mapped to the device.
So if the inside device is listening for SIP on 5060, but you want to use port 9999 on the firewall’s public IP, you would put 9999 in the force Rport. If you don’t, then the device will assume that the same port will be available on the firewall.
SIP (signalling) issue:
The tricky thing is this: if you have 5 SIP devices talking to 5 different external SIP servers, then all of them could (in theory) be src-natted to 5060 on the firewall’s wan interface because the firewall will know that remote host A → my IP 5060 maps back to phone A, remote host B → my IP:5060 maps to phone B, etc… but if all 5 phones talk to the same external server, then the router MUST use a new srcport for each session in SRCNAT so that it can tell the difference between the connections. So if Phone A is the first to register, it may send UDP from port 5060, and nobody else is mapped to 5060 so the firewall keeps the src port un-changed on this connection. Then phone B registers, also using 5060 as the source port. The firewall must use some other port - it could be 5061, or it could be 19784 - only the firewall knows which port it will choose.
Here’s the tricky part about THIS situation - if the sessions are statically configured to use port 5060 as the remote port by both PBXes, then what happens if the behind-nat PBX gets mapped to 19784? The connection won’t work.
This is why you would want to make a static port with a static mapping and then tell the behind-nat PBX about it, so that when it sends out invites, registers, etc, its SIP message will include the reply-address of x.x.x.x:19784 in its messages so that no firewall needs to see the message has <user@192.168.1.56:5060> and go “oh my, this won’t work. I’m going to change this packet just a bit… there…” (and change the message to <user@x.x.x.x:19784>) (This is what the NAT SIP helper tries to do, but SIP is complicated and may use options that the NAT helper doesn’t understand, which is why it often doesn’t work right)
Instead of using nat workaround on the behind-nat-pbx, the server can do the magic.
If the upstream PBX knows how to work around NAT, then what should happen is that whenever it gets a connection from the NAT pbx, it’s going to look at the SIP message:
“hmmm - from 192.168.1.56:5060, eh? Well the UDP packet that this arrived in was from port 19784, and the IP packet it arrived in was from x.x.x.x - so I’m going to ignore what he said his address was, and just use the stuff that was on the packet.”
RTP (media) issue:
The reason you can get 1-way audio is that nowhere in VoIP is it given that you actually want the audio to get sent to the same IP that the SIP is going to… suppose the PBX is also controlling some big mega-gateway with 10000 phone lines on it - the PBX is going to say “send SIP to me, but send audio to my friend here, Mr. Mega Media Gateway” - that is, the SIP reply-destination is x.x.x.x:19784 (either fixed by the main server, or by the firewall, or by the client PBX knowing just what to say) - but the MEDIA destination might be the IP of one of the phones. (e.g. UDP:192.168.1.98:9941)
So see the problem? The SERVER can’t know for sure what to do yet - because it was told to send media to a different IP than the one used in signalling. Suppose the server just shrugs its shoulders and says “I’m going to trust this guy” and starts barfing audio at 192.168.1.98 . . . that can’t make it back to the customer, so the packets are going to end up in a black hole somewhere (in space, no-one can hear you scream). OR - the server might say “I noticed that this PBX is also in 192.168.1.x - maaaybe I should just send the media to x.x.x.x:9941 - yeah, that’ll work.” So now the stream makes it to the customer’s firewall on the port the PBX asked for . . . but what if that port isn’t available? Now the FIREWALL is going to smash these packets with the hammer of Thor, right? Because nobody asked for these packets! If you’re lucky, the phone has also begun sending its audio to the server, using src port of 9941, and by a happy coincidence, the firewall has port 9941 available at the moment, so when the server’s media reaches the firewall, the firewall will recognize that these packets should go to 192.168.1.98 on port 9941, and there is now two-way audio. (yaaay)
So let’s make the public SIP server even more clever - Say the server receives a SIP request (from the known-mapped client of x.x.x.x:5060) for a media destination of 192.168.1.98:9941 - the server will say “haha - this guy still thinks he’s got a public IP but I see where he’s coming from” and ignore the requested 192.168.1.98:9941 and start sending to x.x.x.x:9941 instead. When the phone (if the local PBX doesn’t proxy all media) starts sending RTP to the server using port 9941, the firewall will receive these outbound packets and dynamically map port 9941 to the phone, so when the server’s media reaches the firewall - huzzah! - it will reach the phone.
But there’s one final wrinkle: Remember how the FIREWALL might not agree that 9941 is such a great idea for the media NAT port? If the firewall couldn’t honor 9941, it could start using src-port 10101 for this phone’s media, and when the server sends media to x.x.x.x:9941, the firewall will discard this traffic because it’s not on the right port. (boo)
Well, the server, if it’s clever, can just wait for the nat-pbx (or phone) to start sending audio, and once the first packet arrives, note the packet’s headers’ src address and src port, and just start using THAT as the destination of the media stream, regardless of whatever the SIP messages requested / predicted. In order for this to work, the SERVER must have all media proxied to the server (no direct client-to-client media).
I know this has been long and rambling, and could probably use some proofreading and tidying up, but I’m trying to illustrate down at the packet level EXACTLY what’s happening so that you can understand what the various options really do, and why they are needed or not.
Good luck!
The best solution is to use a VPN to make the client phones see the Asterisk without a NAT. If this is not possible, you may try some workarounds below, but these are never as good as a VPN.
In some NAT scenarios, can use the SIP NAT helper, in other scenarios it makes the situation worse. In general, the helper is good for phones on LAN connecting to a PBX on the internet but not vice versa. And if both your Asterisk runs on a private IP behind a NAT and your client phones connect to it from behind other NATs, and the client’s NAT devices don’t have SIP helpers, it is much harder or impossible to make it work. If you can afford to dedicate a UDP port range on the public IP of the Mikrotik to the VoIP service and forward them to the Asterisk’s private IP, it should be possible to tell the Asterisk that it is seen from outside on that public IP and can use that range of UDP ports, and it will populate the SIP messages accordingly and probably auto-learn the remote RTP sockets from source, so you won’t need SIP helper at the phone-side NAT devices. In this case you need to disable the SIP helper at Asterisk’s Mikrotik as it doesn’t support the auto-learning so it would not permit the RTP from clients to go through to the Asterisk.
If the above is not clear enough, provide a picture of your topology.
Hi.
The Mkrotik Router is RB941-2nD, the Router OS is 6.43.4.
My problem is with voice .
I use Asterisk in Raspberry Pi3 B+
The topology is simple.
ISP ← --Wan Lan <–Pi3
I created two filter rules for sip 5060 and 10 000- 20 000 ports.
And two rules in NAT for the same ports.
My sip work great but 10 000 - 20 000 not.
I tried to put Asterisk host in DMZ, with creating new nat rule for nat every port for this host and voice between sip clients started to work, I delete the nat rule for dmz and my voice work between sip clients again, I can’t understand why?
I tried to disable sip helper and not help.
Yes I know for troubles with put sip in public area but I use Asterisk for education purposes.
I wan’t to connect sip clients from outside without vpn because it’s easy, and I don’t need to configure vpn clients in clients side in Wan side, just give to client only sip account.
And now I am on face with bruteforce attacks…
I use Mangle, Raw and Blacklisting for now, but I see it’s not work verry well.
Because this schema blocks IP addresses in black list, but not all IP addresses…
And I look in asterisk logs and manually I add IP addresses to black list for 247 days.
My next question is how is the best way to protect the router os from flood and bruteforce attacks?
For example I love to use not standard ports to bypass bruteforce attacks, how can I change my sip port to not standart port?
I tried and It is possible I do it but I don’t have voice again?
I change sip port in asterisk, I open this port in mikrotik in filter rules and in nat rules, but no voice?
I am not sure what will happened if in this scenario I put Asterisk in dmz and remove it from dmz, I didn’t try it.
In the past I used Elastix Voip server with Asterisk and then I used simple Huawei not smart router and the schema with different port for sip and the standard range from 10 000 and 20 000 udp ports and everything was fine with simple port forwarding behind nat…
Everything is okay, but I cant understand why I need to put Asterisk host in dmz and remove it from dmz to activate voice to work over udp 10 000 to 20 000 ?
Mikrotik doesn’t have something called DMZ as a one-click setting. For me, a DMZ means that you tell the firewall device to forward every connection establishment attempt which comes from the internet to the WAN-side address of the firewall device to a particular address on its LAN-side. On Mikrotik, such behaviour is implemented using a single dst-nat rule looking only at in-interface and/or dst-address but not at protocol, dst-port etc.
Assuming that you actually don’t want to forward everything coming from outside to the address of Asterisk, but only the SIP signalling and the RTP, I’ve proposed a rule restricted to UDP (presumably carrying RTP) and dst-port range 10000-19999. So you can call it a partial DMZ. You can also include port 5060 to the dst-port list to have everything covered by a single rule.
I don’t understand at all what you mean by putting Asterisk to DMZ and then removing it. Where did you have to configure this? On the Asterisk, on the Mikrotik, elsewhere?
One more thing, while for registering clients, a dst-nat rule is enough, for trunk peers you would also need a src-nat rule for SIP signalling as in this case your Asterisk may send the first packet to the peer.
i have mikrotik router i am having issue with ip telephone i have private lan and i have cisco ip telephone centralized from head office i am having using cisco router to route between offices
i already have 40 mikrotik installed and in all mikrotik i connected ip telephone provided by head office they provided tftp server ip to route for ip telephone and a range of ip
i made static ip connection address and tftp ip i added in route and inside ip telephone i added ip address manuallu with the tftp ip provided by them but the issue is one way traffic
ip telephone not registering i contacted office they told me its the issue of mikrotik router can you please help me out with the configuration
i have one internet ip : in port1 , i have private ip for routing between offices in port 2 and in port 3 i have master port for local network , firewall nat rule is masq and no other rules what should i do
to get everything working please guide me
create a topic dedicated to your issue instead of piggy-backing a loosely related one
post the configuration export of the Mikrotik in that new topic (supposing the issue is the same with all 40 of them), see my automatic signature below on how to prevent leaking any sensitive information
edit your above post with a link to that new topic
