So you put the logging rule just prior to the rule in question. The concept is you want to see all the traffic that gets looked at by the next rule. In-interface=LAN src-address=AdminPC_IPaddressįinally, if you want to implement Sobs idea, which is really a cool use of FW rules for a newbie or me an oldie who has limited knowledge (Faux Guru Status), In-interface-list=RBwin src-address-list=adminaccessĪdd action=accept chain=input comment="Allow LAN DNS queries-UDP" \Ĭonnection-state=new dst-port=53 in-interface-list=LAN protocol=udpĪdd action=accept chain=input comment="Allow LAN DNS queries - TCP" \Ĭonnection-state=new dst-port=53 in-interface-list=LAN protocol=tcpĪdd action=drop chain=input comment="DROP ALL ELSE" log-prefix=\ Interestingly you didn't comment on the UNTRACKED ?Īdd action=accept chain=input comment="defconf: accept established,related" \Īdd action=drop chain=input comment="defconf: drop invalid" connection-state=\Īdd action=accept chain=input comment="Allow ADMIN to Router" \********************************** I like the idea of your logging rule to see which traffic is being dropped to understand from the LAN Side what traffic is being blocked which you may wish to allow.
There may be need to allow port 53 to the router and any other service as well.
#MIKROTIK LOOPBACK INTERFACE PC#
Thus to address that I should state at least one other rule that I use in my own config (allow admin PC access to router via input rule). The rule in question does not permit traffic from the LAN explicitly its simply dropping traffic not from the LAN.Īhhh, okay so that traffic is not blocked with the OPs setup but as soon as I add my drop all input rule then LAN traffic is blocked. However we need to safeguard admin access to the router via the Input chain as a FIRST STEP!! So that external attempts to access the router are still effectively stopped during the brief time period while changing the rules (assuming live connection to the internet). The INPUT drop all else rule (last rule) should be installed prior to removing the rule noted in (1). Hi Sob, not sure what you meant (discuss below) but it did get me to thinking about another slight modification. (4) What you need to add as last rule in the forward chain.Īdd action=drop chain=forward comment="Drop all else" (3) This rule in effect permits port forwarding but configured in a drop rule - a weird not-intuitive approach.īut I prefer (allow rules in user rules) and a cleaner looking/reading rule!Īdd action=allow chain=forward comment="allow port forwarding" connection-nat-state=dstnat (2) In the forward chain, I am not sure why untracked is there but if is part of the default it must be okay?Ĭonnection-state=established,related, untracked ? (1) In the Input chain I would take this rule.Ĭhange it to this (as this rule includes everything noted above and more and put it as your last rule in the input chain.Īdd action= drop chain=input comment="Drop all else" !dstnat connection-state=new in-interface-list=WAN Add action=accept chain=input comment="defconf: accept established,related,untracked" \Ĭonnection-state=established,related,untrackedĪdd action=drop chain=input comment="defconf: drop invalid" connection-state=invalidĪdd action=accept chain=input comment="defconf: accept ICMP" protocol=icmpĪdd action=accept chain=input comment="defconf: accept to local loopback (for CAPsMAN)" dst-address=\Īdd action=drop chain=input comment="defconf: drop all not coming from LAN" in-interface-list=!LANĪdd action=accept chain=forward comment="defconf: accept in ipsec policy" ipsec-policy=in,ipsecĪdd action=accept chain=forward comment="defconf: accept out ipsec policy" ipsec-policy=out,ipsecĪdd action=fasttrack-connection chain=forward comment="defconf: fasttrack" connection-state=\Īdd action=accept chain=forward comment="defconf: accept established,related, untracked" \Īdd action=drop chain=forward comment="defconf: drop invalid" connection-state=invalidĪdd action=drop chain=forward comment="defconf: drop all from WAN not DSTNATed" connection-nat-state=\
0 kommentar(er)
