I have a MIkrotik RB4011iGS+ router. I’ve been using it successfully for a few years. It has one internal network 192.168.89.0/24 and one Internet connection. I have ports 80 and 443 forwarded to an internal web server (192.168.89.7).
I wanted to create a DMZ where the web server can live separately from all other servers and computers so if it is hacked, the hacker cannot easily access the other servers and computers. I also need to be able to access the web server via SSH on port 22 (or some other port so it can still be managed).
So I decided to create a new bridge called bridge-dmz and assign ethernet port 8 to bridge-dmz and gave it an IP of 192.168.111.1. There is no DHCP server for the network. I connected my web server to port 8 on the Mikrotik and assigned it a static IP address 192.168.111.2. I changed my NAT rule to forward ports 80 and 443 to the web server’s new address (192.168.111.2). So far to this point, all is working as expected.
Now I want to block access from the 192.168.111.0/24 network to 192.168.89.0/24 so I added a firewall rule:
After I create the filter rule, I cannot access the web server from any internal host on 192.168.89. I cannot SSH to it on port 22 and I cannot see web pages on port 80 or 443.
Use WG to access the router config and any server… forget the idea about SSH.
Use existing bridge for LAN subnet
Create a second subnet just for the server and assign that to a specific port.
a. remove ether4 from bridge
b. change name of ether4 to ether4-server
c. /ip address
add address=192.168.X.1/24 interface=ether4-server network=192.168.x.0
PLUS
ip Pool of 5 lets say
dhcp-server
dhcp-server network
@anav, you’re getting silly with your worshiping of WG. To connect between two subnets off same router … really?
@OP:
firewall filter rule order matters very much. Your rule drops any packets with origin in 192.168.111.0/24 and destination in 192.168.89.0/24. And this includes packets, which are replies to connection setup attempts, started in opposite direction. The problem can be solved in multiple ways, the best (if firewall more or less resembles default config, where one of early rules is to accept connection-state=established,related) is to push your drop rule after those rules. In this case the initial packet (of 3-way TCP handshake) will (possibly) be allowed, the rest of packets will be handled by mentioned rule (because those will be recognized as established or related).
Another pissibility is to ammend your rule with additional property connection-state=new so that rule will only drop packets which are not part of already allowed ongoing connections (i.e. new connection attempts).
That’s not what he was referring to. At least not how I understood.
He only suggested to use WG as replacement for ssh access. Which is IMHO a very valid response.
I think anav would never suggest what you think he did
Well, @OP wrote that he wanted ssh access from his LAN to a DMZ host … and @anav replied with post where he dismissed ssh in favour of WG.
And let’s forget that WG doesn’t allow any particular management connection type, it’s simply transport tube. So if server offers ssh as means for management , then OP wpuld have to use ssh even with WG. Firewall rules would be different, overhead larger and security … roughly the same IMO.
Yes, I write many posts on my tab … where keyboard tactile feedback is … non-existant. So in average I make one typo per word. Because of that I proof-read all of my posts and fix all typos I notice. So I manage to reduce typo rate to one per sentence (give or take).
Another pissibility would be if I posted less … I wonder if this would be better?
Thanks especially to mkx for your help. My rule was already below the established and related accept rules, but when I added connection-type=new to my drop rule, it started working as I expected. I have upgraded the firmware recently to 6.49.7 so the default rules I have may not be correct by today’s standards. Here are the filter rules I have now.
I really just wonder at this point if I’m missing some filter rules I actually need. Would you mind looking at it and giving me some direction there? Thanks.
Currently I’m in “leisure” mode and not fit to think about somebody else’s firewall rules. Instead a hint: it’s always possible to see factory default config which comes with ROS installed on the device.
Open terminal window (or ssh into device), make it as wide as possible, then execute command /system default-configuration print … use it as inspiration to enhance your firewall setup.
The general concept of default firewall is “accept what’s needed, drop everything else” … the other way around (“drop what’s forbidden, accept everything else”) is inherently less secure as it’s impossible to think about everything that needs to be forbidden … if one uses the former concept and forgets to allow something, a nice user will remind firewall’s admin about it
