In general, the default firewall for RouterOS works fine after a factory reset - but one issue that plagues newbies and leads to a lot of posts here is that the default firewall rules protect the default WAN interface (usually named ether1-gateway). This configuration assumes that ether1-gateway is configured as a dhcp-client. When users re-configure their router as a pppoe-client, they often forget to update the firewall rules accordingly. When you use pppoe, the public IP interface is no longer any physical etherX interface, even if the modem is connected to ether1-gateway. The IP address is moved off of that interface and onto pppoe1-out.
The fix is to go into the firewall rules and look through the filter and nat tables to make sure that any rules with in-interface=ether1-gateway get changed to be the pppoe interface instead (also out-interface=ether1-gateway should be updated). Most people catch the nat rules because the Internet doesn’t work until these are fixed, but once it starts working, they often forget to check the filter rules too.
So once you’ve made sure of that, then you’ll want to tackle the VoIP QoS - which unfortunately is not easily explained in a nutshell. There are various QoS how-to guides in the Wiki that you can read, but here’s the basic strategy.
- You must classify VoIP packets using packet marking rules in the mangle table.
- You then configure queues with the priority settings that guarantee priority handling to VoIP traffic.
Part 1 can be done in various ways - if your IP telephony device(s) send their traffic with the appropriate DSCP values, then you can use this to match traffic. Inbound from the Internet is another story, though, because almost certainly your voip provider’s packet marks (dscp) have been wiped off of the traffic by the Internet before it reaches you.
If you do a packet capture, you can look at the SIP (I assume you’re using SIP) packets to see what DSCP values are set. Usually SIP will be dscp 26. (I think - it’s going to be twenty-something) - in general, SIP is easily matched by just looking for protocol=udp and port=5060 because SIP is pretty consistent that way.
The media (RTP) is another story, though. It may be on any port (almost never 1024 or below, though) and may or may not be to/from the same IP address as the SIP registrar/proxy IP address. Perhaps your provider has documentation as to what IP range(s) their services use and what ports their RTP uses. If so, then you can match RTP by matching UDP to/from those ranges, even if DSCP is not being set to 46 (also known as ‘ef’ - aka express forwarding)
So, let’s say your provider’s service always comes from / goes to IP addresses in the range of 192.0.2.0/24
You could mark this traffic using the mangle table as follows:
/ip firewall mangle
add chain=prerouting connection-mark=no-mark action=jump jump-target=classify
add chain=prerouting connection-mark=voip action=mark-packet new-packet-mark=voip passthrough=no
add chain=classify src-address=192.0.2.0/24 protocol=udp action=mark-connection new-connection-mark=voip
add chain=classify connection-mark=no-mark action=mark-connection new-connection-mark=besteffort
add chain=classify action=return
This will classify all connections as “voip” or as “besteffort”
Packets within any connection marked as “voip” will then get marked individually with the packet mark “voip” (packet marks are different than connection marks)
All other packets will not be marked at the packet level. The connections are marked as besteffort just so that the connection tracking won’t bother attempting to classify the traffic for all packets in the flows. Basically, the “classify” chain will only get called for each new connection the router sees.
Okay - now you need to set up queueing.
The simplest way to do this would be to make a queue tree for upstream traffic and parent the tree to the pppoe interface, and then do the same for your LAN interface.
Make two queues (the queue type doesn’t really matter - default should be fine)
Call one WAN and call one LAN, and set the parent of each queue to be the WAN and LAN interfaces. Set max-limit=2M or 1500K - or whatever your bandwidth is. Be sure to set this for each direction and it’s better to make the queue slightly “slower” than the real connection speed just so the queue can completely control the bandwidth properly - ESPECIALLY in the upstream direction. If you’re using DSL and the connection quality drops due to rain for instance, then your router may forward traffic faster than the line can actually transport it - which will lead to packet loss…
But anyway, once you have these two queues set, you create two sub-queues for each one:
LAN-voip
LAN-besteffort
WAN-voip
WAN-besteffort
Set the parent for LAN-xxxx to be the LAN queue you already created, and the WAN-xxxx queues to use WAN as their parent.
Set max-limit on your best-effort queues to whatever you like - I usually set it to something ridiculous like 1G. This is because the actual limit comes from the parent queue. A sub-queue can have a SMALLER max-limit, which means that queue cannot use 100% of the bandwidth… this is what you do for the voip queues though, so VoIP cannot starve your entire connection. If you only have a few maximum connections, then 100Kbps per connection should be perfectly fine.
Let’s say you have 3 lines, then set max-limit=300k for the voip queues.
Then set priority to 8 on the best-effort queues and 1 on the voip queues.
Also set the packet mark for the voip queues to match the “voip” packet marks, and set the marks to match best-effort queues as just “no-mark” so they’ll catch the rest of your traffic by default.
Finally, set a guaranteed minimum bandwidth value on the child queues - usually 256k works just fine - the priority will take control once each queue reaches its guaranteed minimum bandwidth.
Ok - so in review:
WAN / parent=pppoe1-out / max-limit=1500k (or whatever is appropriate for your connection)
WAN-voip / parent=WAN / max-limit=300k / limit-at=256k / priority=1 / mark=voip
WAN-besteffort / parent=WAN / max-limit=1g / limit-at=256k / priority=8 / mark=no-mark
etc…