Hello,
have Synology NAS. DSM (webmin) is running on port 7580. All I want is acess to this webmin from lan only so I want to block it for access from WAN.
Synology: 10.65.1.10
PC in LAN: 10.65.1.15
I tried some rules but don’t work. Can you show me the right way?
Thank you.
Please show your configuration.
Good day, I am also new to Mikrotik but in general unless you have created a specific firewall rule and probably a NAT rule (my lack of knowledge now obvious) poking holes for that port, the default rules on the mikrotik would block unsolicited access to any ports on your LAN devices.
What version of firmware are you using?
What IP firewall rules are in place now?
Another thought, isn’t there a setting on nas, to only accept local connections or maybe even from specific ip or range?
I already deleted rules because don’t work. Maybe synology has option to do that but I want to use limit it via mikrotik.
My question would be why do you need a rule to drop the WAN traffic to the Synology specifically? Surely your already in place and secure firewall would drop this by default? Also you must have some sort of dst-nat set up if WAN traffic can make it through to the Synology, if you don’t have a dst-nat rule then WAN can’t get to it anyway.
If you do not have a firewall already, please at the very minimum apply something like the below (changing WAN to your WAN-interface name). This is basic but functional and will also squash any problems you may have with traffic getting to the Synology.
/ip firewall filter
add action=accept chain=forward comment="ACCEPT established & related" connection-state=established,related in-interface=WAN
add action=accept chain=input comment="ACCEPT established & related" connection-state=established,related in-interface=WAN
add action=accept chain=input comment="ACCEPT ICMP" in-interface=WAN protocol=icmp
add action=drop chain=forward comment="Drop invalid" connection-state=invalid in-interface=WAN
add action=drop chain=input comment="DROP invalid" connection-state=invalid in-interface=WAN
add action=drop chain=input comment="DROP ALL" in-interface=WAN
add action=drop chain=forward comment="DROP ALL FROM WAN NOT DST-NAT" connection-nat-state=!dstnat in-interface=WAN
add action=drop chain=forward comment="DROP RFC1918 outbound" dst-address-list=RFC1918 out-interface=WAN
^That is a slightly edited version of my full script found on my website https://www.steveocee.co.uk/mikrotik/basic-firewall/
Hi Steveocee,
I am a bit confused by your rule order?
I am a newbie so I am unsure but I have been lead to believe that order of rules is very important, for example input rules before forward rules etc.
Shouldnt it be more like:
[input]
1- INPUT DROP invalid connections
2- INPUT ACCEPT established, related and untracked
3 - INPUT DROP all not coming from LAN
[forward]
4-FORWARD ACCEPT established, related and untracked
5-FORWARD DROP invalid connections
6-FORWARD DROP all from WAN not DSTNATed
It looks like you leave ‘untracked’ out of your ACCEPT rules and wondering why?
I believe the ICMP allow is not mandatory and unless there is some benefit would it not better to keep this port closed??
I am confused as to the purpose of this rule…
add action=drop chain=forward comment=“DROP RFC1918 outbound” dst-address-list=RFC1918 out-interface=WAN?
Order of rules is very important within one chain, because there the packets go from the beginning, until a matching rule is found. But you can mix different chains as much as you want. I find it confusing, but it’s just a matter of personal preferences.
Untracked packets don’t just appear by themselves, you need to tell them to be untracked in raw table. If you know that you don’t to that, you do not need to worry about them.
Allowing ICMP is not mandatory, but it’s not like blocking it makes you really safer, so why bother (and if you do it with IPv6, it will break things).
RFC1918 are private addresses (192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) and the goal of that rule is to prevent them from leaking out.
Okay thanks Sob,
How would the private addresses ‘leak out’, dont they get translated to the WANIP before leaving home?
(Is this rule expressed in other ways on different devices?)
From the above code of Steveocee is missing the following part that must be before the code of Steeveocee.
Of cource Steveocee mentioned that the full code is in his website https://www.steveocee.co.uk/mikrotik/basic-firewall/
/ip firewall address-list
add address=192.168.0.0/16 list=RFC1918
add address=172.16.0.0/12 list=RFC1918
add address=10.0.0.0/8 list=RFC1918
Thanks JB, I still dont understand why those rules are there. I have not seen any other set of rules in my travels where the OP thinks they have to put rules to block private LAN IP addresses from reaching the WAN.
Hmmm Q1, is this the way to effectively create a LAN to WAN rule DROP? So all private LAN devices only have access to its own LAN and perhaps other LANS?
Q2. Another puzzling thing to me is where In our Rules I state outgoing packets get associated with Source NAT.
For return packets don’t they have to be tagged with that in order to be come through the standard filter NAT rule??? (DSTNated)
Look closely, the rule has dst-address-list=RFC1918 and out-interface=WAN, so it’s when destination is in one of those subnets and packet tries to go to internet. If your LAN is e.g. 192.168.88.x and something tries to connect to 192.168.222.10, router will happily send it to ISP’s router (default gateway). But you don’t want that, because a) it can’t reach any sensible destination anyway and b) that address might belong to some remote network, currently unavailable because you VPN disconnected, so if you send these packets to ISP, you might in theory leak something secret.
Return packets are handled by connection tracking. And to make it short, router just knows what packets belong to each connection.
And OP is not very clear, 10.65.1.10 is private address, it’s not reachable from internet, unless there are forwarded ports (dstnat rules) for it from the router with public address. So if some of its ports should not be reachable from internet, then the good start is to not forward that port at all.
Firstly Thank you @JB172 for spotting my mistake and even correcting it for me and also @Sob for explaining my madness!
@anav, to answer your question, this rule is a bit of a “hang over” from something I had to fix through work. We were operating 192.168.1.0/24 LAN side with pppoe_out for WAN connectivity with a public routed IP. A device in the LAN wasn’t as “legitimate” as it should have been and decided to try and send a heavy stream of UDP out to a 172.16.3.X address, the router of course checked it’s local addresses, didn’t have it so sent it up the pppoe tunnel where the traffic was eventually dropped at the pppoe server however not without causing temporary detriment to the network the traffic was travelling up.
The rule is purely to stop that kind of behaviour re-occurring and keep anything destined for a LAN address from going out the WAN interface, a rare occasion but nevertheless you’d be amazed how much traffic it actually catches!