Hi. Fasttrack doesn’t appear to be working (counter at zero on the firewall, dummy rule on zero bytes) on my RB5009 router. AFAIK, the Fasttrack Firewall rule is in the right place and is formed correctly, but no fasttrack.
Can anyone help? I’m sure it’s a trivial mistake. Config attached (with a few entries deleted).
D.
fasttrack.rsc (6.07 KB)
So far dont see why…
(1) Set this to NONE as mac-server by itself is not a secure access method!
/tool mac-server
set allowed-interface-list=listBridge
(2) I am not a bond expert so the bridge ports look fine, was just wondering if the non-slave port needs to be the one on the bridge and not the bond, but its only a theory with .05% of having validity.
(3) I prefer to include all possibilities or leave blank… I typically use firewall rules to narrow down to finite IPs, so your approach is fundamentally good, but you are removing your wireguard connection from being able to configure router by not including it ??
set winbox address=10.160.100.0/24
Otherwise this rule is useless…
a_dd action=accept chain=input comment=“Allow Everything in Wireguard”
in-interface=wireguard1_
(4) As an exercise disable funky doh cloudflare stuff to see how that may or may not affect speed tests!
(5) Do local users access the plex server and if so is it strictly directy by LANIP address??
(6) Redundant rule… Can you see why the first rule is NOT required.
(add action=drop chain=input comment=“Block external DNS requests” dst-port=53
in-interface=WAN_Port log=yes log-prefix=“External DNS Request” protocol=udp
add action=drop chain=input comment=“block everything else”
(7) Improve your Input chain.
/interface list member
add interface=local list=listBridge
add interface=wireguard1 list=listBridge
add interface=Vodafone list=WAN
add interface=WAN_Port list=WAN
/ip firewall address
add address=admin-desktop_IP list=Authorized
add address=admin-laptop_IP list=Authorized
add address=admin-ipad/iphone_IP list=Authorized
add address=remote-admin_IP list=authorized comment="wireguard remote"
/ip firewall filter
add action=accept chain=input comment="accept established, related,untracked" \
connection-state=established,related,untracked
add action=drop chain=input connection-state=invalid
add action=accept chain=input comment="accept ICMP" protocol=icmp
add action=accept chain=input comment="wg handshake" dst-port=13231 protocol=udp
add action=accept chain=input comment="admin access" in-interface-list=listBridge src-address-list=Authorized
add action=accept chain=input comment="user services" in-interface=local dst-port=53,123 protocol=udp
add action=accept chain=input comment="user services" in-interface=local dst-port=53 protocol=tcp
add action=drop chain=input comment="block everything else"
(8) You main issue → PHUCKING TOO FANCY fastrack rule…
remove this sheite frankenstein!!
add action=fasttrack-connection chain=forward comment=“Fasttrack not IPSEC”
connection-mark=!ipsec connection-state=established,related dst-limit=
1,5,dst-address/1m40s hw-offload=yes limit=1,5:packet psd=21,3s,3,1 time=
0s-1d,sun,mon,tue,wed,thu,fri,sat
WITH
/ip firewall filter
add action=fasttrack-connection chain=forward comment=Fasttrack \
connection-state=established,related hw-offload=yes
add action=accept chain=forward connection-state=\
established,related,untracked
add action=accept chain=forward in-interface=listBridge out-interface=Vodafone
add action=accept chain=forward comment="Allow Wireguard to Subnets" \
dst-address=10.160.100.0/24 in-interface=wireguard1
add action=accept chain=forward connection-nat-state=dstnat
add action=drop chain=forward comment="Drop all Else"
(2) bond (much like bridge) at the same time entity which distributes traffic between two or more physical links and is interface for higher layers. So yes, it’s bond interface that has to be bridge port, not slave interfaces (used as links).
@OP: what the hell is the fasttrack construct supposed to do?
Thanks. As usual, you have sorted out my problem. I don’t know how that fasttrack rule got modified the way it was, but just replacing the Fasttrack rule sorted it out. When you set these rules up using WinBox there isn’t a hw offload switch, so maybe not doing it by the command line was the problem? I wonder how many other rules are affected by that if so.
The speed actually wasn’t limited - even in software I was getting the max upload and download speeds - but the CPU load has gone from 30% to 4% when speedtesting.
PS. On the config I sent I deleted some of the wireguard and IPSEC sections for public consumption - maybe I’m being too paranoid. That’s why it didn’t look like certain things were configured or orphaned in the setup.
D.
Fastrack bypasses software processing for established and related connections, once they’re initially established. If you don’t use it then you’ll see the CPU usage go up. Not a deal-breaker for an RB5009 (30% CPU with 930Mb/s traffic, reducing to 4% with Fasttrack on) but a lowlier box, like my previous RB750GR3, would max out at maybe 2-300Mb/sec and be variable in throughput without Fasttrack, cf. a similar 4% CPU use and full bandwidth when Fasttrack is active.
You can’t use Fasttrack with IPSEC connections, which is why my config marks IPSEC traffic and exempts it from the Fasttrack rule.
Simple rule but with a big effect.
It’s clear why you excluded ipsec traffic. But what about those packet rates etc.?
what do you mean? Why is it so much faster? Because it’s matching on connection, not processing individual packets. That way the packets get processed in the switch hardware, avoiding the CPU - which might limit the packet processing speed. If I connect a remote server to a LAN PC and initiate a download, I shouldn’t need to decide what to do with every packet once I’ve established the connection, so I can avoid any processing logic on the CPU.
Fast track rule from published export is this:
add action=fasttrack-connection chain=forward comment=“Fasttrack not IPSEC”
connection-mark=!ipsec connection-state=established,related > dst-limit=
1,5,dst-address/1m40s > hw-offload=yes > limit=1,5:packet psd=21,3s,3,1 time=
0s-1d,sun,mon,tue,wed,thu,fri,sat
What is the highlited part meant to do? Specially the *limit crap … and time is completely redundant.
And I guess that combination of connection marking and firewall rules is overly complex. I think you would get to same result (having IPsec not fast tracked) by having only fiter rules (without mangle rules):
/ip/firewall/filter
add chain=forward action=accept ipsec-policy=in,ipsec comment="defconf: accept in ipsec policy"
add chain=forward action=accept ipsec-policy=out,ipsec comment="defconf: accept out ipsec policy"
add chain=forward action=fasttrack-connection connection-state=established,related comment="defconf: fasttrack" hw-offload=yes
add chain=forward action=accept connection-state=established,related,untracked comment="defconf: accept established,related,untracked"
These are, BTW, default firewall rules (the top-most rules in default ruleset for forward chain) and they are the same since quite some versions. I added the last one just to give some context, the important ones are the first three which replace the mangle rule you have and your fast track rule.
Adding “hw-offload=yes” on fasttrack rule is in most cases redundant. HW offloaded firewalled traffic only works if hardware supports it (only a few device models do) and if L2 setup allows it (having WAN interface off bridge is not appropriate in this context).
Apologies. I hadn’t checked that you were an expert (and I’m definitely not, though, for a second, I thought I might actually know more than someone else on here 
), so answered the wrong question. The additional FastTrack options in the config was something bogus - I’m not even sure how it got enabled, but it wasn’t on purpose. That was breaking FastTrack.
Thanks for the filter rule handling suggestion for ipsec. I might try that - it isn’t currently broken though, so is there a benefit of using your suggested approach and not mangle? The reason I mangle it is because I use a site-to-site VPN and split tunnel the traffic, so I’d mark it anyway.
Mangle and fasttrack are not compatible. Hence it’s good to avoid mangle rules if it’s possible. If you have to use them anyway (meaning you have to take care what to fasttrack and what not), then I don’t think there’s much of a difference (if any).
Even in the case of the NPTv6 pair of rules that @Sob has provided?
Which makes it possible to have stable (ULA) IPv6 addresses and multihoming on a SOHO network despite regularly changing IPv6 prefixes.
AFAIK fasttrack is not yet supported in IPv6. But when it will be supported in IPv6, rules by @sob won’t be compatible … without properly configuring firewall filter rules (either fasttrack rule or rules above fasttrack rule).
The thing is: according to packet flow, when connection is fasttracked, any packet belonging it will bypass most of packet processing stages. Essentially it’ll skip everything after connection tracking machinery and mangle comes after connection tracking machinery. Thus in order to keep mangle rules to work as intended, it is necessary to exempt packets that need to be processed by mangle rules from being fasttracked. This can be done either by explicitly accepting such connections before fasttrack rule (as is in my example which quoted default filter rules) or by excluding such connections by adding aporopriate selection properties to fasttrack rule itself (as is in the “non-broken” rule by @OP).
First of all thanks for the detailed explanation and pointing me to the relevant part of the documentation.
One question tough: what is your expectation when or if any time IPv6 FastTrack will be implemented in ROS v7, will the
FastTrack handler also supports source and destination NAT, so special exceptions for NATed connections are not required.
apply to snpt and dnpt actions (NPTv6) too as it seems less resource hungry than NAT66 or IPv4 NAT at least at first glance?
By the way do I understand right that the RAW table (stateless firewall) is applied even on (currently IPv4 only) FastTracked connections? If yes than would it be feasible for NPTv6 connections to stick with stateless firewall (RAW) as it is already the more nuanced one for IPv6 and let the stateful firewall (filter table) go?
I’m not MT employee so clearly I don’t know anything about MT’s plans and timelines.
According to packet flow diagram that is indeed so. Can NPTv6 be done in RAW? Probably yes, with caveats: RFC4291 defines link-local address space as fe80::/10 … and stateless NPT would work only if external address prefix would match it … but no ISPs hand out such short prefixes to end users (either homes or businesses), those are commonly /60 or /56 … or even /48 in rare cases. However, in practice link-local addresses are often in fe80::/64, in this case stateless NPT would be possible. With a few variants (e.g. if LAN side consists of multiple IPV6 subnets, do we use separate public subnets in NPT. Do we try to squeeze all in single public /64 and how do we deal with conflicts is devices in different LANs use same LL address?).
So basically, stateless NPTv6 is probably possible, but with many caveats.
BTW, I don’t see stateful firewall filter for IPv6 go in normal deployments. Stateless firewall is not really good for end devices which sporadically open ports to access services on WAN side, it’s stateful firewall that deals with such use cases. Stateful firewall is also necessary for services which need protocol helpers (e.g. FTP) … even on server side.