After a bit of advice on a config I am trying to set up (and already have in place) and whether I am on the right track.
I have a few VLANs in play on my RB3011. I have set up a forward rule that blocks all traffic between each VLAN, then there are a few specific rules allowing certain ports between my main LAN and a pair of DMZ VLANs I have.
Basically, I have had to set up two forward rules for each communication path, one with ‘Source A’ to Source B with specific ports and then ‘Source B’ to ‘Source A’ with the same specific ports to allow it to work - ideally I only allow some of these one way but I can’t seem to figure it out - what am I missing? Or is this how it should be?
Without any details from your side, also a generic suggestion - you can always use src-address-list, dst-address-list and/or in-interface-list, out-interface-list if the same rule should work for multiple sources and destinations. Whether it makes more sense to use a single rule and multiple items in address lists and interface lists to which this rule refers or to use multiple rules (because the number of symmetric cases vlan A ↔ vlan B is low) depends on your particular situation.
To carry on the idea a bit further, multiple VLANs is about the time I start using jump actions to jump from the forward chain to custom chains such as “vlan 1” and “vlan 2”.
For example, the address list used in the rule below covers all of my internal production subnets. In this particular case, prod.int defines subnets that are on an equal trust level, such as domain-joined Windows client PCs. My prod.in chain allows traditional Windows PC to Windows Server communications such as file sharing, NTP, DNS, etc. the prod.in chain does not allow unexpected behavior, such as a client PC scanning the server subnets, for example.
I just keep building and compartmentalizing my rules into separate chains as needed for scale.
The added benefit of using a src-address-list as opposed to interfaces is that your source addresses might change to a different ingress interface if you have multiple routes available. If a circuit goes down, suddenly a source IP might appear on a different ingress interface. If you specify an ingress interface in your filter, the traffic may not be forwarded.
It depends. If you make use of the stateful firewall concept (so you have an action=accept connection-state=…,established,… rule somewhere at the top of the input and forward chains of /IP firewall filter), a rule permitting the client initiating a connection to send the initial packet of the connection to a listening server is enough; if you don’t, you have to provide rules for both directions of the communication.