Second, would be a tool that can trace a packet through the system from beginning to end. This has been requested several times, going back several years (v3 or earlier?):
This is not possible, because “any” protocol does not have a “dst-port”.
Port numbers are only specified for certain protocols, and for every protocol they are at a different position.
So there is no possibility to do such a match.
The underlying code also does not offer the option of e.g. “protocol=tcp/udp” what is what you probably are after.
When you say “underlying code,” I presume that you’re talking about the kernel? In that case, s/any/all:
[!] -p, --protocol protocol
The protocol of the rule or of the packet to check. The specified protocol can be one of tcp, udp, udplite, icmp,
icmpv6,esp, ah, sctp, mh or the special keyword “all”, or it can be a numeric value, representing one of these
protocols or a different one.
Supporting protocol=tcpudp|either|whatever, would be as simple as iterating through the indicated protocols in the abstraction layer to dynamically generate the rules in the kernel. Probably the same way they do address lists, which is not supported by iptables directly. This would also be the mechanism for supporting the service-list feature I suggested. Not supported by the kernel, but likely easy to support in the abstraction layer.
Either way, dealing with protocols/services in bulk is probably not worth any heroic efforts, but it would make firewall rules much easier to read in some cases.
This isn’t correct. IP sets is another feature of netfilter. Using it in Linux is a little less straightforward because there are several hash types that are optimal for different scenarios… but once you have the list set up, you add and remove entries from it just like in ROS, and you can call it in an iptables chain rule with the -m set --match-set MYSET src (or dst) criteria.
Although, ipset does support a set-of-sets type of set, so your wish list #3 should be quite doable for ROS.
I agree that a “packet trace” tool would be helpful.
ipset also supports port lists, so the “service list” should also be doable.
I sense that you’re an ASA guy wanting Mikrotik to be more like ASA. My company’s DMZ firewall has a lot of rules and I would’ve been screwed long ago w/o the packet trace tool, but I like the iptables way of doing things better than ASA’s ingress/egress rule processing. I find it to be more flexible, especially the ability to look ahead at the output interface while forwarding, or back at the input interface - all in one chain of rules.
I use custom chains in Mikrotik to keep things organized whenever I have a longer list of stuff to do. If you wanted a chain that only happens when in-interface is ether4, for instance, make a rule that says in-interface=ether4 action=jump jump-target=ether4-in (for instance)
Your comment about the protocol ‘all’ shows that you don’t quite understand pe1chl’s reply - saying protocol = any is fine, but you can’t specify a port in iptables unless you also specify a protocol that uses ports. If you say protocol=all in Linux, then it won’t let you put any port numbers:
root ~# iptables -A foo -p all -m multiport --dports 10,20,30 -j RETURN
iptables v1.4.21: multiport needs `-p tcp', `-p udp', `-p udplite', `-p sctp' or `-p dccp'
Try `iptables -h' or 'iptables --help' for more information.
It might make things easier to read - and I presume that if netfilter had a “tcp/udp” matcher built into it, it would be a little more efficient to use one rule to block port X on both protocols - but then again, two separate rules might actually process faster with simpler match criteria than a single rule with a more expensive check to perform…
p.s. - since there’s no packet trace tool, a useful way to debug a firewall is to create a simple rule that matches what you’re looking for, and action=passthrough. Enable logging if you like - the log also shows the nat state if I recall correctly.
Move this rule up and down in the chain and see where it gets hits and where it stops getting hits. You know the offending rule is after your test rule if the test rule gets hits, and you know the offending rule is before the test rule if the test rule doesn’t get any hits.
Not really an ASA guy, per se, though I have a couple and find some of the features of the ASA very nice to work with.
As for the whole protocol stuff, I’m just going on what I find when searching google for “iptables address list,” which comes back with several results, all of which suggest that it’s not supported. Now I have more to look at. At any rate, my requests are what they are. I’m not a coder, otherwise, I’d be rolling out my own systems instead of asking for features to ROS to make it easier to use.
