Hi,
I am using RB951G default configuration with couple minor tweaks. Now I want to run webserver at my local network on eth5.
What is the best way to isolate webserver traffic from my internal network ?
I am thinking about vlan’s or different IP subnet for eth5.
Any suggests greatly appreciated
I have the same question, I think using the route rule would be ideal for a total isolation, but it would remove the facility webserver administration from the local network.
simple use different network on ether5, then drop communication between server and local network in firewall forward chain.
first check is ether5 not to slave - in default config ether2 is master on ether3-5
yup im agree with him, use different network, then use forward chain drop in firewall rules
I tried this but it did not work, because even if different networks, the routes are known by the RB in the route table.
And I also tried to create a rule in the forward dropping all traffic from network 1 to network 2, did not work, icmp worked usual between the two networks.
You probably have some other rule before your drop one, which accepts the traffic.
Be careful that you’re not testing this by pinging the Mikrotik’s “DMZ” interface from the LAN and concluding that ICMP is allowed, because even though you have a client 192.168.2.44 trying to ping the server network 192.168.3.1 (the Mikrotik’s interface on the server network), this doesn’t go to the forward chain, but the input chain.
I tried from a pc to another pc.
Work with firewall rule on chain forward.
Then almost certainly there’s a rule before your block rule which allows the traffic. Perhaps it’s just a simple “allow ICMP” rule- which would mean that you could ping between the networks, but nothing else (i.e. no file sharing, no http, etc)
Have you tried to access any services across the router? (remote desktop would be an easy-to-do test)
In any case, look at your forward chain closely, and determine which rule is allowing pings (and maybe all services) to cross the firewall. My money’s on ICMP, or else a strangely-configured rule whose logic has gotten twisted.
these are my rules in the forward chain: can you give any suggestions for improvement of safety?
0 ;;; Drop Invalid on Forward
chain=forward action=drop connection-state=invalid log=no log-prefix=“”
1 X ;;; Forward - Accept State New from local-network to DMZ
chain=forward action=accept connection-state=new
src-address-list=RedesLocais dst-address-list=RedeDMZ log=no
log-prefix=“”
2 ;;; Forward - dst-nat accepted ports
chain=forward action=accept connection-nat-state=dstnat protocol=tcp
in-interface=ether1 dst-port=80,8081,3389,37777,22,5060 log=no
log-prefix=“”
3 ;;; Forward - State New from DMZ to www - Accept
chain=forward action=accept connection-state=new src-address-list=RedeDMZ
dst-address-list=!RedesLocais log=no log-prefix=“”
4 ;;; Forward - All State Related and Stablished Accept
chain=forward action=accept connection-state=established,related log=no
log-prefix=“”
5 ;;; Forward - SSH Port to DMZ from local-networks - Accept
chain=forward action=accept protocol=tcp src-address-list=RedesLocais
dst-address-list=RedeDMZ dst-port=22 log=no log-prefix=“”
6 ;;; Forward - Drop all from DMZ to Local-network
chain=forward action=drop src-address=192.168.16.252
dst-address=10.2.2.0/24 log=no log-prefix=“”
7 ;;; Forward - State New from local-network Accept
chain=forward action=accept connection-state=new
src-address-list=RedesLocais log=no log-prefix=“”
8 ;;; Forward - Drop everything else
chain=forward action=drop log=no log-prefix=“”
Do this instead for your firewall forward filters: (I left the index numbers the same as your existing rules so that you can easily see how to re-order them)
0 ;;; Drop Invalid on Forward
chain=forward action=drop connection-state=invalid
4 ;;; Forward - All State Related and Stablished Accept
chain=forward action=accept connection-state=established,related
3 ;;; Forward - State New from DMZ to www - Accept
chain=forward action=accept out-interface=ether1
1 X ;;; Forward - Accept State New from local-network to DMZ
chain=forward action=accept src-address-list=RedesLocais out-interface=DMZ-INTERFACE-NAME
(from this point, any packet MUST be in the new state so there’s no need to check for that on any rules)
2 ;;; Forward - dst-nat accepted ports
chain=forward action=accept connection-nat-state=dstnat protocol=tcp
in-interface=ether1 dst-port=80,8081,3389,37777,22,5060
5 ;;; Forward - SSH Port to DMZ from local-networks - Accept
chain=forward action=accept protocol=tcp src-address-list=RedesLocais out-interface=DMZ-INTERFACE-NAME dst-port=22
(note that this rule isn’t necessary if rule 1 X ;;; is activated but I assume you’re testing)
6 ;;; Forward - Drop all from DMZ to Local-network
chain=forward action=drop src-address=192.168.16.252
dst-address=10.2.2.0/24 log=no log-prefix=“”
7 ;;; Forward - State New from local-network Accept
chain=forward action=accept connection-state=new
src-address-list=RedesLocais log=no log-prefix=“”
(rules 6 and 7 aren’t necessary)
8 ;;; Forward - Drop everything else
chain=forward action=drop
sorry I did not understand, why the rule that drops the DMZ traffic to the Local Network is not necessary, if in my understanding is that which is isolating the networks and protecting my local domain.
Because the last rule drops any packet that reaches it.
If you never accept a packet from DMZ to LAN in some earlier rule, then it’s eventually going to reach the final rule where it will be thrown into the black hole of “drop all packets”
Think of the chain like falling into a pit.
Each rule is a tree branch growing from the side of the pit for packets to grab onto if they match its conditions.
If there is no branch for them to grab onto, they fall all the way to the bottom and get crushed.
And by the way, rule 7 isn’t necessary because rule 3 got modified to accept any packet which is going out the WAN interface, regardless of where it came from. Rule 7 would never match anything because it already got accepted by rule 3, so it’s a waste of CPU cycles to check again.
I understand what you said, but, before putting this rule, DMZ packages freely passed to LAN. Maybe because I have a NAT Rule Masquerad from local-network address list to !local-network address list.
srcnat chain only needs one rule:
Action=masquerade out-interface=ether1
Another possible reason would be if you have the DMZ addresses in your local address list.
Ok - I just re-read your original rules. Rule 7 is what allowed lan>DMZ connections. Replies were allowed by the established/ related rule.
I tested the rules you suggested and it really worked, I can not ping from dmz to lan, and the ssh connection work, even without the rule that accepted the tcp port 22.
But I’m thinking of not accept all new state packages from lan to dmz, only the specific ports Which I want to use.
Thats all, thanks a lot for your help.
PS… I dont know how to rate you and increse your reputation.
In general, lan to DMZ is ok - it’s DMZ to lan that needs policing. But definitely tune it as needed.
I think you can click a person’s profile to rate them now. Thanks for thinking about karma though. 