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.
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.
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.
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.
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 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.
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…
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.