The syntax of the firewall rules may be quite confusing for a newbie.
Each firewall rule has the following types of parameters:
- action - what to do with the packet if it matches the rule's match conditions
- chain - in which chain within a "table" (raw, mangle, nat, filter) the rule is placed
- match conditions - names of "physical" fields of the packet header (like dst-address or protocol), or of packet meta-fields, which do not exist in the packet itself but have been attached to it during handling by previous stages of the firewall (such as packet-mark or connection-bytes). Each such field name comes with a list of values, ranges, or prefixes which the value in the field has to match in order that the condition would match. A rule matches if all of its conditions match.
- action parameters - usually new values of packet header fields or packet metadata fields to be assigned when the action is performed
The group to which a given parameter belongs is not explicitly stated (even in the documentation), so you have to read the field description in the documentation, use common sense, and experiment where neither of the former two is sufficient. So in particular, connection-mark
is a match condition, whereas new-connection-mark
is an action parameter; dst-address
is a match condition whereas to-addresses
is an action parameter - the new value of either destination address or source address depending on whether it is used in dstnat
chain of the nat
So as an example, a rule in /ip firewall mangle
saying chain=prerouting action=mark-connection connection-mark=none new-connection-mark=my-mark
assigns the connection mark my-mark
to any packet it receives for inspection provided that its metadata contain no connection-mark
is a reserved match value).
is a spefic metafield because it is used to ensure the same handling to all packets belonging to the same "connection", i.e. a TCP session or a bi-directional UDP stream. As soon as the firewall rule assigns a connection-mark
to a packet, that connection-mark
is stored in the metadata of the whole connection, so each subsequent packet found to belong to that connection gets the same connection-mark
automatically when passing through the connection tracker, which is a "hidden" but very important part of the firewall between the raw
stage and the mangle
When using PCC in particular, you can only deal with LAN->WAN connections, so you don't need to use connection-mark
s because the PCC rules inspect the same fields of each packet which the connection tracker does, so all packets of the same direction of the same connection match the same PCC rule. But when you use nth
to choose the WAN, or when you need connections initiated by a device in the internet to be responded through the same WAN interface through which they came in, you need connection-tracking to ensure that all packets of a connection will be routed out via the same and proper WAN. See more here
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.