Hi!
Is it possible to setup L2/bridge firewall and somehow use connection tracking on TCP connections? My wish is to allow connections to be initiated from one way only while allowing only established the other way. I want both in and out interfaces to have the same subnet to work transparently.
From from what I read here it is not possible to have two different interfaces with same subnet and use normal L3 firewall and use normal NAT (with connection tracking) to forward between the interfaces which was my first thought but using the same subnet for both interfaces will confuse the router.
If you set bridge to use IP firewall, then it should be possible:
/interface bridge settings
set use-ip-firewall=yes
Beware that this setting is common for all bridges on device (if there are multiple). Also one needs to be careful about exact firewall rules defined, using rules for bridge traffic is slightly different than using rules for routed traffic.
Also, if bridge is HW offloaded, you need to undo the offload. At least for the port(s) you actually want to be subject to firewall filter rules. You do that by setting hw=no on bridge ports. However this causes considerable performance drop on certain device models (most notably CRS switches).
Hi!
Yes I looked at that setting but couldn’t figure out exactly how it works. Do I configure my L2 rules in /ip firewall then? Does IP firewall take over or is bridge filter still enabled simultaneously?
This is low throughput so performance does not matter
When use-ip-firewall is enabled, then all packets passing bridge (the software part if HW offload is active) are subject to L3 firewall (raw, filters, NAT, the whole lot of it). And that’s on top of bridge filters (which again only work for traffic which is not HW offloaded). If you care about performance, then use bridge filters and/or firewall raw rules as they are less resource demanding. OTOH they lack connection tracking machinery hence some things are not possible to do.
I can’t stress enough the “not HW offloaded” part of it. If bridge can offload traffic to underlying switch chip (depends on particular device model and ROS version), then that traffic is not seen by software running on CPU and hence none of processing (bridge filters, ip firewall) doesn’t take place.
Ah, thanks
Yes, I do understand the hw offload part but thanks for the hint
Btw, any thoughts how I could also protect the “secure” side from the “unsecure” side from unknown IPs since I do need to allow ARP for it to work transparently? Someone could easily configure something wrong by selecting a already used IP and that way disturb traffic on the “secure” side Can I somehow filter which ARP packets to forward maybe? There are only two IPs on the “unsecure” side the “secure” side need to talk to.
Can’t you just create another IP subnet for the “unsecure” side? And route between both sides? It’s RPITA when you mix trustworthy and untrustworthy devices in same subnet (both L2 and L3) because you can’t really cover all the problems that might arise.
You can filter according to MAC address using bridge filters. The problem is that it’s not possible to use MAC address lists … you can only use some MAC address prefix. So you probably have to create number of almost identical bridge filters.
Ah, thanks again
Short story, my problem is that these “unsecure” devices are now managed by the company that produced the unit they are in and they have their own way in (LTE modem with VPN) to them and I certainly don’t want them reaching the rest of my network. Once their guarantee has ended I want to fully integrate these devices in my network by simply removing the firewall and their VPN entrance without having to change a lots of IPs.
Can I somehow filter which ARP packets to forward maybe? There are only two IPs on the “unsecure” side the “secure” side need to talk to.