Community discussions

MikroTik App
 
dandrzejewski
newbie
Topic Author
Posts: 41
Joined: Fri Oct 09, 2015 5:39 am

Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 10:21 am

I've got one of the default rules in my firewall - v7.1, hEX S.

/ip/firewall/filter
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related

When this rule is enabled, it's passing traffic from the other end of a wireguard connection to hosts on my internal LAN. If I disable "established" it drops the traffic from that host as it should.

Am I doing something wrong? I have a lot of firewall rules in here but to troubleshoot, I disabled every rule except my default drop rules and this one.
 
User avatar
smyers119
Member Candidate
Member Candidate
Posts: 232
Joined: Sat Feb 27, 2021 8:16 pm
Location: USA

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 10:32 am

Reference this article, to hopefully help you better understand what's going on.

https://help.mikrotik.com/docs/display/ ... c+Concepts
 
dandrzejewski
newbie
Topic Author
Posts: 41
Joined: Fri Oct 09, 2015 5:39 am

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 11:20 am

I've reviewed that article.

As for established connections, which when disabled fixes the problem:

ESTABLISHED - The ESTABLISHED state has seen traffic in both directions and will then continuously match those packets. ESTABLISHED connections are fairly easy to understand. The only requirement to get into an ESTABLISHED state is that one host sends a packet and that it, later on, gets a reply from the other host. The NEW state will upon receipt of the reply packet to or through the firewall change to the ESTABLISHED state;

The rule is toward the top, and there are no other rules that would allow that connection.

If I disable every rule except my last drop rules, the connection is dropped. If I then ONLY enable the rule I specified above, the connection is then allowed. Based on the description above from the wiki, it seems like this connection should never make it to the ESTABLISHED state because there's nothing to allow the packet through initially.

And for what it's worth, fasttrack is disabled.
 
User avatar
jvanhambelgium
Forum Guru
Forum Guru
Posts: 1114
Joined: Thu Jul 14, 2016 9:29 pm
Location: Belgium

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 1:09 pm

INPUT chain perhaps ?
Traffic TROUGH the Mikrotik to a backend host is FORWARD chain.
So it will not "match" hence it will be allowed if you disable your final "DROP ALL" rule.
 
WeWiNet
Long time Member
Long time Member
Posts: 610
Joined: Thu Sep 27, 2018 4:11 pm

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 1:34 pm

Please provide your firewall export. Pretty sure you missed something.
On firewall problems, you need log the accept or drop rules that causes you problems.
Ideally refine a copy of the rule to make sure it catches only traffic you searching for (else Log becomes too big).
You might need to add for this input or output i/f, traffic type, source or dest IP address etc.

PS: Your input accept establish is needed at least for LAN side as it is needed for DHCP requests, DNS lookups, NTP etc.
If you disable this rule and then there is a drop all rule at the end you will for sure break something.
 
R1CH
Forum Guru
Forum Guru
Posts: 1108
Joined: Sun Oct 01, 2006 11:44 pm

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 3:11 pm

That is expected behavior if the wireguard tunnel terminates on the router. If you want to control what the packets inside the tunnel can reach once they are in your network, you need to set up rules on the forward chain.
 
dandrzejewski
newbie
Topic Author
Posts: 41
Joined: Fri Oct 09, 2015 5:39 am

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 5:41 pm

That is expected behavior if the wireguard tunnel terminates on the router. If you want to control what the packets inside the tunnel can reach once they are in your network, you need to set up rules on the forward chain.
So you're saying that packets entering through a wireguard interface will already be in the "established" state?
 
dandrzejewski
newbie
Topic Author
Posts: 41
Joined: Fri Oct 09, 2015 5:39 am

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 5:55 pm

Please provide your firewall export. Pretty sure you missed something.
On firewall problems, you need log the accept or drop rules that causes you problems.
Ideally refine a copy of the rule to make sure it catches only traffic you searching for (else Log becomes too big).
You might need to add for this input or output i/f, traffic type, source or dest IP address etc.

PS: Your input accept establish is needed at least for LAN side as it is needed for DHCP requests, DNS lookups, NTP etc.
If you disable this rule and then there is a drop all rule at the end you will for sure break something.
So I can reproduce this particular issue with almost every rule disabled, so here's what's left:
/ip firewall filter
add action=accept chain=input comment="defconf: accept established,related" connection-state=established,related
add action=accept chain=input comment=wireguard dst-port=51820 protocol=udp src-address=192.241.191.219
add action=drop chain=input comment="defconf: drop all not coming from LAN (e.g. WAN)" in-interface-list=!LAN log=yes log-prefix="[DROP NOT FROM LAN] "
add action=drop chain=forward comment="defconf:  drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN log=yes log-prefix="[DROP WAN NO DSTNAT] "

As soon as I disable the first rule in the script above, it stops allowing connections from the remote wireguard endpoint into the LAN. Enable it, it starts allowing them again.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21895
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 6:15 pm

Instead of debating,,,,
Please post your full latest config.
/export hide-sensitive file=anynameyouwish

That way we will able to understand in context the relationship between the wireguard settings, the firewall settings and the IP routes and other rules that are part of the glue.

In general, any VPN that is established to the router is what I call a FAUX LAN. In the sense that it is on the same LEVEL as the LAN but is like a separate vlan and thus needs to be included and rules made to allow it to reach the internet through the routers WANIP, or reach subnets etc..............
 
whatever
Member
Member
Posts: 366
Joined: Thu Jun 21, 2018 9:29 pm

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 8:22 pm

You have to distinguish between the vpn/wireguard connection itself, which will always be established once it's established (hence the name), and the data tunneled through this connection which might hit the forward chain instead of input, depending on its destination address.

Nothing in your forward chain denies connections from wireguard to lan, therefore everything is allowed. Works as expected.
 
User avatar
anav
Forum Guru
Forum Guru
Posts: 21895
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada
Contact:

Re: Firewall "Established" rule allowing more than I'd expect.

Wed Dec 15, 2021 9:53 pm

Tis what happens if you dont have a last rule of block all ........... With that in place the admin can then control what is allowed!!!
 
R1CH
Forum Guru
Forum Guru
Posts: 1108
Joined: Sun Oct 01, 2006 11:44 pm

Re: Firewall "Established" rule allowing more than I'd expect.

Thu Dec 16, 2021 8:36 pm

That is expected behavior if the wireguard tunnel terminates on the router. If you want to control what the packets inside the tunnel can reach once they are in your network, you need to set up rules on the forward chain.
So you're saying that packets entering through a wireguard interface will already be in the "established" state?
No, they won't be considered as input at all unless their destination is the local IP of the router. They will go straight to forwarding.

Who is online

Users browsing this forum: ciruliss, Elvis1991 and 28 guests