Hello, I have moved my new servers to new subnet and it’s speed is slow, about 40 MB/s and going down to 20 MB/s.
I was first thinking that there is problem with my server (since my old server in the same subnet as my computer has normal 1Gbit speeds), but after hours of trying to find problem in my server I found a tip - try to disable firewall.
Well, speeds raised to 60 MB/s.
Then I tried to enable fasttrack and it maxed up to 120 MB/s!
So my question is - can you please help me with my firewall? How to set it properly?
And also please check if there are no other mistakes
Yes, but it’s when I enable fasttrack (that default pre configured rule).
But I need to know, how to set up my firewall properly
I have little experience with setting up firewall so. I’d appreciate help with it so I won’t have any security holes in it
I need to get that 120 MB/s. I have 40 with my provided config
It’s quite fine to enable fasttrack, overall your firewall rules are fine with regard to that. The observed 40 MBps (that’s around 300Mbps) is somehow maximum that hAP ac can sustain according to test results … I usually look at figure for routing with 25 rules and for medium-sized packets which quite well correlates with what I observed so far.
Here’s my view on your firewall rules:
add action=accept chain=input comment="defconf: accept ICMP" protocol=icmp # this one is fine
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related # this one is fine
add action=drop chain=input comment="defconf: drop all from WAN" in-interface=ether1 # this one is fine
add action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=established,related \
disabled=yes # you can enable this one
add action=accept chain=forward comment="defconf: accept established,related" connection-state=established,related # this one is fine
add action=accept chain=input protocol=igmp # surely you have good reason for this one
add action=accept chain=input protocol=udp # you should make this one more selective by adding dst-port= ....
add action=accept chain=forward protocol=udp # this one should as well be made more specific by using dst-port=, in-interface=, out-interface= src-address= etc.
add action=drop chain=forward comment="defconf: drop invalid" connection-state=invalid # this one is fine
add action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=\
!dstnat connection-state=new in-interface=ether1 # this one is fine
add action=accept chain=forward comment="share printer between vlans" \
dst-address=192.168.0.21 src-address=192.168.5.0/24 # this one is probably fine ...
# you might make it more specific by defining port range and protocol appropriate for net printing protocol in use
add action=accept chain=forward comment="share tv between vlans" \
dst-address=192.168.0.26 src-address=192.168.5.0/24 # same comment as for rule one above
add action=drop chain=forward comment="drop all between vlans" \
dst-address=192.168.0.0/24 src-address=192.168.5.0/24 # this one is probably fine
add action=drop chain=forward dst-address=192.168.1.0/24 src-address=\
192.168.5.0/24 # this one as well
# for both rules above you could get the same result by using ( in-interface or in-interface-list ) and (out-interface or out-interface-list )
#
# All nat rules seem fine with me. You could simplify the last 4 rules by using another interface list
# with members bridge_vlan10 and bridge_vlan20 and using in-interface-list=<vlan_interface_list_name>
# instead of in-interface=bridge_vlan?0
#
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" \
out-interface=ether1
add action=masquerade chain=srcnat comment="Hairpin NAT" dst-address=\
192.168.1.0/24 src-address=192.168.1.0/24
add action=redirect chain=dstnat comment="Intranet DNS" dst-port=53 \
in-interface=bridge_vlan10 protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface=\
bridge_vlan10 protocol=udp
add action=redirect chain=dstnat dst-port=53 in-interface=\
bridge_vlan20 protocol=tcp
add action=redirect chain=dstnat dst-port=53 in-interface=\
bridge_vlan20 protocol=udp
Generally firewall implicitly allows all connections. Some people firmly believe that proper thing is to place a rule
/ip firewall filter
add chain=forward action=drop
and then add needed accept filters above it. I believe that either way (explicitly allow and drop everything else VS deny a lot of things and allow all the rest) one can build a safe firewall but in both cases one has to understand how things work … And I also believe that non-masters (myself included) should build on a good foundation, laid by default configuration, instead of designing things from scratch (and missing whole lot of aspects creating plenty of holes in such firewall).
If I just enable fasttrack, it will work for everything which goes through router (since there is nothing specified like interface,…), right? So if I have bandwidth limit via queues on subnet 192.168.5, it will also go around it at full speed, won’t it?
In my case I need fasttrack only between subnets 192.168.0 and 192.168.1., nothing else. How to edit it to allow it only for this?
Thank you for your firewall review. I just kept default pre configured firewall and then started looking on internet for proper configuration of additional things I wanted / needed.
Yup, fasttrack is against queuing. There’s way out of it: construct fasttrack that will only trigger on traffic that can be fasttracked … or accept the “should-not-be-fasttracked” traffic before fasttrack rule. Performance-wise the order doesn’t matter since when a connection is fasttracked, it can’t get un-fasttracked. Mind that the following “normal” accept should always be below the fasttrack rule.
If you really want only fasttrack traffice between said subnets, you could replace existing fasttrack rule with something like
add action=fasttrack-connection chain=forward comment="fast track from 192.168.0 towards 192.168.1" connection-state=established,related src-address=192.168.0.0/24 dst-address=192.168.1.0/24
add action=fasttrack-connection chain=forward comment="fast track from 192.168.1 towards 192.168.0" connection-state=established,related src-address=192.168.1.0/24 dst-address=192.168.0.0/24
Quite possibly you actually don’t need the second rule, connection should be hit by the first rule in next step (return packet traveling from server 192.168.0.x to client 192.168.1.y). While this might seem notable difference in practice it’s not (it’s just a fragment of a second difference, should not affect average throughput by much). Having only single rule instead of two might increase performance of those connections not being served by rules above fasttrack rules as every packet has to check against every rule until there’s a match.
with fast-track enabled you can still do queuing as long as that queue is attached (parent) to an interface.
Simple queues or global parents are indeed incompatible with fast-track.
Do note that fast-track is a connection level flag: once a connection is fast-track-ed, most of it’s packets, in any direction, will use the optimised stack. Most because some packets will be processed in normal manner to ensure connection tracking is kept up to date.
And since it’s on the level of connection, marking once is enough.
