The order of Access Lists and Control Lists determines what actually happens to traffic because rules are evaluated in sequence and the first match wins. As a packet is processed, the device checks each rule from top to bottom and applies the action of the first rule that matches. That means where you place a specific deny or permit changes the outcome for many packets. For example, if you want to block a single host but allow others, you must place that block rule before any broader permit rule; otherwise the broad permit might match first and the block would never take effect. There’s usually an implicit deny at the end for anything that doesn’t match any rule, which reinforces why you must be explicit about what should be allowed. This is why the order is important for implementing the intended traffic policy.

PPP-based tunnels establish encryption through negotiation between the two peers. Neither side fixes the algorithm in advance; instead, each end advertises its supported encryption options and the tunnel settles on the strongest common option. That’s why encryption is determined by the highest match between client and server—the strongest cipher both sides support is automatically chosen during setup. You can influence the result by configuring what each side allows, but you don’t pick a single cipher in the tunnel configuration itself.

In RouterOS, firewall rules are organized into two sections with different purposes and chain concepts. The Filter section handles general packet filtering and uses the chains that describe where a packet is in its journey: input for traffic destined to the router, forward for traffic passing through the router, and output for traffic generated by the router itself. The NAT section deals with address translation and uses the NAT actions src-nat (source NAT) and dst-nat (destination NAT) to rewrite addresses as packets enter or leave the network. So, the correct pairing is that Filter uses Forward, Input, and Output, while NAT uses src-nat and dst-nat. The other options mix these roles, which doesn’t align with how RouterOS structures firewall rules.

Custom chains are a way to organize firewall rules into logical blocks, making complex filtering policies easier to read and manage. In RouterOS, you can put a group of related rules into a single custom chain and use a jump from the main chains (like input or forward) to that chain. The rules inside the custom chain run, then control returns to the main chain. This modular approach lets you reuse and modify a whole set of rules in one place, or apply the same block of rules from multiple places without duplicating them. For example, you could create a custom chain for all VPN-related filtering and jump to it from several interfaces. Then you keep the VPN rules centralized in that chain, keeping the primary chains clean. Custom chains don’t increase throughput by themselves, don’t encrypt rules, and don’t define routes. They’re simply a tool for organizing and modularizing policy.