I have uPnP enabled so that inside hosts can request incoming connections.
I also have…
0 X chain=forward action=accept protocol=icmp
1 X chain=forward action=accept connection-state=established
in-interface=ether1-gateway
2 X chain=forward action=accept connection-state=related
in-interface=ether1-gateway
3 X chain=forward action=reject reject-with=icmp-network-unreachable
in-interface=ether1-gateway
Note that they’re disabled. With them enabled, incoming connections don’t work. I guess I can’t really be surprised by that. What I’m really asking for is the best practice for this case.
It’s been suggested that it’s not sensible to rely solely on NAT to secure the inside hosts. At the same time, if the inside hosts request an incoming port forwarding via uPnP, then the firewall should allow it. But is that then not exactly equivalent to just using NAT as your firewall?
If there were a magic rule like “chain=forward action=accept allowed-by=uPnP” to stick between rules 2 and 3 above, then what would the forward firewall above actually be achieving?
It will allow all of the UPnP rules through. This logic is that anything that is destined for your router from the outside world would go to your public ip, and, therefore, your input chain. When UPnP opens the port forwards it changes the destination from your public ip to the machine and port the packet is destined for. The end result is, due to the dynamic NAT rule created by UPnP, traffic becomes accepted as your dst-address (only for the upnp specified ports, as all the others are NOT being forwarded by a NAT rule) becomes one within your LAN (192.168.1.0/24) and through the forward chain.
edit: please bear in mind that the rule above is to be placed in ip>firewall>filter If I have been misinformed in any way, please someone feel free to correct me.
In my case, the router is acting as a simple home gateway, so the one question I have left is… what’s the difference between your proposed ruleset and the null ruleset?
I ask because I can’t think of anything the router is going to be forwarding anything that isn’t to or from the 192.168.1.x network.
I guess I’ll watch the logs to see if the reject rule at the end of the forwarding chain actually catches anything
I use this method myself, and the accept rule is right above a “drop all” rule for the forward chain. All other accepts/drops are in the rules above it. I have not seen anything but packets from a port forward go through.
This explanation was given to me by another networking guru. Although my experience has been a good one, I was thinking of posting this information anyway just to let other eyes on this forum look at it and see if the logic makes sense to them as well. I wouldn’t want to recommend anything that creates a gaping security hole.
Well, sure, but I was told in this forum that not having a forward chain at all was not a best security practice.
What I can’t quite wrap my brain around is that now my forward chain doesn’t seem like it’s adding any value. Either I’m right - and it isn’t; or it’s achieving something I can’t think of - which I’d like to understand.
Well, the forward chain is for routed packets. You’re using NAT for UPnP devices, so they’re handled by the NAT chain. I’m not sure the Forward chain is doing anything at all in this scenario.
So can it be said (or confirmed by Mikrotik) that a upnp nat rule does not require a firewall filter rule that accepts it?
For instance, if you have a firewall filter rule to drop all forward chain packets from the internet interface, the upnp nat rule will accept them regardless?
Hosts at same broadcast domain on WAN interface can reach your private LAN by adding route like <YOUR_LAN_NETWORK> via <YOUR_WAN_IP> until you forbid such forwarding. This is serious security issue. I recommend to add forward drop/reject. Of course you need some “accept” rules, at least for established connections. I dont know how to get working upnp forwarding in this scenario without adding accept forward rules for specified ports
