Is missing connection-state=invalid hugely bad?

hendry · Thu Aug 31, 2017 5:29 am

Hi,

I setup a Firewall https://www.reddit.com/r/mikrotik/comme ... _for_home/ like so

add action=accept chain=forward comment="LAN traffic can go anywhere" in-interface=aa
add action=accept chain=forward comment="Established traffic" connection-state=established
add action=accept chain=forward comment="Related traffic" connection-state=related
add action=accept chain=forward comment=ICMP protocol=icmp
add action=drop chain=forward comment="Drop the rest"
add action=accept chain=output
add action=accept chain=input comment="LAN traffic can go anywhere" in-interface=aa
add action=accept chain=input comment="Established traffic" connection-state=established
add action=accept chain=input comment="Related traffic" connection-state=related
add action=accept chain=input comment=ICMP protocol=icmp
add action=accept chain=input comment="allow ssh" dst-port=22 protocol=tcp src-address=MY.TRUSTED.SPECIAL.IP
add action=drop chain=input comment="Drop the rest"

I did this pretty much manually since the first Google result for Miktotik Firewall took me to https://wiki.mikrotik.com/wiki/Firewall which I found overwhelming. So I wrote the above almost by hand.

Later I found https://wiki.mikrotik.com/wiki/Manual:I ... all/Filter which is better. Better would be some inline Firewall option in Webfig to create a sane default. Quickset's firewall option is far too opaque and risky!

So should I be worried that my initial Firewall configuration missing those "Drop Invalid connections" rules?

karlisi · Thu Aug 31, 2017 1:35 pm

So should I be worried that my initial Firewall configuration missing those "Drop Invalid connections" rules?

No.
These examples are a little outdated, i.e., established and related can be in one rule.

add action=accept chain=forward comment="" connection-state=established,related

Thu Aug 31, 2017 2:00 pm

Drop invalid rule is necessary if you use NAT on your router. It is possible that for different reasons packet can leave router with wrong (LAN) IP address. This firewall rule will drop such packets.

hendry · Thu Aug 31, 2017 4:07 pm

Drop invalid rule is necessary if you use NAT on your router. It is possible that for different reasons packet can leave router with wrong (LAN) IP address. This firewall rule will drop such packets.

Oh, I don't use NAT, so I guess I'm fine?

gmiller01 · Fri Sep 22, 2017 12:40 pm

Drop invalid rule is necessary if you use NAT on your router. It is possible that for different reasons packet can leave router with wrong (LAN) IP address. This firewall rule will drop such packets.

I have a problem with this rule. Sometimes drop packets from VPN clients, sometimes doesn't.
How can I debug it, why some packets are invalid, and others not?
I have added an exception to VPN addresses, so I have solved the problem, but I want to know what is the root of this problem.

pcunite · Fri Sep 22, 2017 6:43 pm

This should be the default setup on MikroTik. I know those new to RouterOS must be overwhelmed. You don't need hundreds of drop rules, unless you want to log them.

About Drop invalid rules:
We need support to confirm this, but basically it is possible for a packet to look like it was established or related, when in fact it really was not. These are packets that have been crafted to seem this way. However, RouterOS knows that a three way handshake did not exist for them. Thus, they are invalid. Without the drop invalid rule, I'm guessing, that RouterOS will accept them in the established~related rule?

I would rather they simply go passed that rule and hit Drop All for performance reasons. Can support please confirm if we need Drop invalid given my rules below? According to what I've read about IPTables, the INVALID state is different from Established and Related, thus, if you use my firewall rules, they will hit my drop all. Better performance since invalid is a rare packet type for me.

Reading on the subject.

/ip firewall filter
add chain=input action=drop connection-state=invalid comment="Drop invalid"
add chain=input action=accept connection-state=established,related comment="Accept established related"
add chain=input action=accept in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=input action=drop comment="Drop all other input"

add chain=forward action=drop connection-state=invalid protocol=tcp comment="Drop invalid"
add chain=forward action=accept connection-state=established,related comment="Accept established related"
add chain=forward action=accept connection-state=new in-interface=bridge-LAN comment="Allow LAN access to router and Internet"
add chain=forward action=accept connection-nat-state=dstnat comment="Accept Port forwards if configured"
add chain=forward action=drop comment="Drop all other forward"

/ip firewall nat
add chain=srcnat action=masquerade out-interface=ether-WAN comment="Default masq"
add chain=dstnat action=dst-nat in-interface=ether-WAN protocol=tcp to-addresses=1.2.3.4 dst-port=123 to-ports=123 comment="Sample Port Forward"

majestic · Sat Dec 10, 2022 2:18 am

I can also bare witness that sometimes they can be valid when mikrotik believes they are not.
Tonight I was debugging an issue where a site to site VPN done via netmaker on another server, which routes several blocks over, found that packets was being dropped. I can understand why because they didn't originate via this vLAN but over the VPN, however they are geninune never the less.

drop_invalid forward: in:vlan2910 out:vlan2910, connection-state:invalid src-mac 00:11:32:XX:XX:XX, proto ICMP (type 0, code 0), 10.29.10.10->10.27.10.253, len 84

It would be good to know if we can safely remove this rule, but going by what I read, I believe with the post above that it should be fine as last rules are drop if nothing matches anyways.

mkx · Sat Dec 10, 2022 11:32 am

It would be good to know if we can safely remove this rule

Generally it's not safe to remove this rule ... as much as it's not safe to remove any other firewall rule. If some rule drops packets that are not supposed to be dropped, then one really should investigate the reason. Default firewall ruless are pretty fine if the rest of device config is (close to) default as well. As soon as one starts to make non-trivial changes (adding a VPN is non-trivial change regardless to the ease of adding such interface as it changes network layout considerably), config has to be considered holistically.

As to particular log entry: it is impossible to even start commenting on it without knowing firewall rules in detail, possibly knowing network layout and intended traffic patterns as well.
One particular thing which can happen in environment with multiple routers (VPN endpoint is a router) is routing triangles (where packets in one direction take one path and packets in opposite direction take different path) ... and stateful firewalls, placed in "wrong triangle corner", don't like that.

majestic · Sat Dec 10, 2022 12:15 pm

Thank you very much for your reply @mkx.

So to get an idea of the layout, I am enclosing below:

So we have a RB5009 which feeds this site, there are seveal vlans setup, nothing too special. A couple of remote ways into winbox/ssh and a server in the lan but all are ACL down to a few selected IPs. We also have a bond over two links which feed the network.

The VPN client itself (wireguard but managed by netclient) is running on a server on 10.29.10.100 and the RB5009 has several routes which is routing the traffic to it, so that everyting on the LAN knows how to reach those addresses.

Note, I only have two routes for the VPN defined atm due to this issue and testing is easier with a smaller subset of rules/routes to look though.

There is currently two sites defiend (10.27.0.0/24 and 172.19.255.0/24) as I was testing to see if the problem was on all and it is. Only when the invalid rule is disabled, it then works as expected.

Below I have dumpted the relivent parts of the config which hopefully will explain a little more then I can in words.

Please let me know if theres something you need to be clarified or if I have missed something.

Thanks in advance for your help.

Kind Regards,

Simon

Interfaces/VLANs


/interface bridge
add admin-mac=18:FD:74:XX:XX:XX auto-mac=no disabled=yes name=bridge
/interface ethernet
set [ find default-name=ether1 ] comment="CISCO | SW01 | LAG| PORT 1" poe-out=off
set [ find default-name=ether2 ] comment="CISCO | SW01 | LAG | PORT 2" poe-out=off
set [ find default-name=ether3 ] disabled=yes poe-out=off
set [ find default-name=ether4 ] disabled=yes poe-out=off
set [ find default-name=ether5 ] disabled=yes poe-out=off
set [ find default-name=ether6 ] disabled=yes poe-out=off
set [ find default-name=ether7 ] disabled=yes poe-out=off
set [ find default-name=ether8 ] disabled=yes poe-out=off
set [ find default-name=sfp-sfpplus1 ] comment="City Fibre | ONT"
/interface vlan
add comment="XX Broadband | VLAN" interface=sfp-sfpplus1 name=vlan911 vlan-id=911
/interface bonding
add comment="CISCO | SW01 | LCAP" mode=802.3ad name=bond0 slaves=ether1,ether2 transmit-hash-policy=layer-2-and-3
/interface pppoe-client
add add-default-route=yes comment="XX Broadband | Internet" disabled=no interface=vlan911 name=pppoe0 use-peer-dns=yes user=XXX@XXX.XX.XX
/interface vlan
add comment="Core | Network" interface=bond0 name=vlan2910 vlan-id=2910
add comment="Trusted | Network" interface=bond0 name=vlan2920 vlan-id=2920
add comment="Work | Network" interface=bond0 name=vlan2930 vlan-id=2930
add comment="Guest | Network" interface=bond0 name=vlan2950 vlan-id=2950
/interface list
add name=WAN
add name=LAN
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/interface bridge port
add bridge=bridge comment=defconf interface=ether3
add bridge=bridge comment=defconf interface=ether4
add bridge=bridge comment=defconf interface=ether5
add bridge=bridge comment=defconf interface=ether6
add bridge=bridge comment=defconf interface=ether7
add bridge=bridge comment=defconf interface=ether8
add bridge=bridge comment=defconf interface=sfp-sfpplus1
/interface list member
add comment=untagged interface=bond0 list=LAN
add comment=untagged interface=sfp-sfpplus1 list=WAN
add comment="Core | Network" interface=vlan2910 list=LAN
add comment="Trusted | Network" interface=vlan2920 list=LAN
add comment="Work | Network" interface=vlan2930 list=LAN
add comment="Guest | Network" interface=vlan2950 list=LAN
add comment="XXX | Broadband" interface=vlan911 list=WAN
add comment="WAN | Internet" interface=pppoe0 list=WAN

Firewall Rules & ACLs


/ip firewall address-list
add address=XX.XX.19.5 comment="Dad's | Home" list=TRUSTED
add address=XX.XX.123.10 comment="Simons | Home" list=TRUSTED
add address=XX.XX.24.146 comment="Steven's | Work" list=TRUSTED
add address=XX.XX.79.236 comment="Trudie's | Home" list=TRUSTED
add address=10.29.10.0/24 comment="Core | Network" list=TRUSTED
add address=10.29.20.0/24 comment="Trusted | Network" list=TRUSTED
add address=XX.XX.52.120 comment="Hetzner | Dedicated" list=TRUSTED
add address=******* comment="Steven's | Home" list=TRUSTED
/ip firewall filter
add action=accept chain=input comment="accept established,related,untracked" connection-state=established,related,untracked
add action=accept chain=input comment="accept to local loopback" dst-address=127.0.0.1
add action=jump chain=input comment="allow icmp" jump-target=icmp
add action=drop chain=input comment="drop invalid" connection-state=invalid
add action=jump chain=input comment="allow access to router" jump-target=router
add action=drop chain=input comment="drop all not coming from LAN" in-interface-list=!LAN
add action=accept chain=forward comment="accept in ipsec policy" ipsec-policy=in,ipsec
add action=accept chain=forward comment="accept out ipsec policy" ipsec-policy=out,ipsec
add action=fasttrack-connection chain=forward comment=fasttrack connection-state=established,related hw-offload=yes
add action=accept chain=forward comment="accept established,related, untracked" connection-state=established,related,untracked
add action=drop chain=forward comment="drop invalid" connection-state=invalid log=yes log-prefix=drop_invalid
add action=jump chain=forward comment="allow access to lan" jump-target=lan
add action=drop chain=forward comment="drop all from WAN not DSTNATed" connection-nat-state=!dstnat connection-state=new in-interface-list=WAN
add action=accept chain=icmp comment="0:0 and limit for 5 packets per second" icmp-options=0:0-255 limit=5,5:packet protocol=icmp
add action=accept chain=icmp comment="3:3 and limit for 5 packets per second" icmp-options=3:3 limit=5,5:packet protocol=icmp
add action=accept chain=icmp comment="3:4 and limit for 5 packets per second" icmp-options=3:4 limit=5,5:packet protocol=icmp
add action=accept chain=icmp comment="8:0 and limit for 5 packets per second" icmp-options=8:0-255 limit=5,5:packet protocol=icmp
add action=accept chain=icmp comment="11:0 and limit for 5 packets per second" icmp-options=11:0-255 limit=5,5:packet protocol=icmp
add action=accept chain=router comment="accept udp dns queries from lan" dst-port=53 in-interface-list=LAN protocol=udp
add action=accept chain=router comment="accept tcp dns queries from lan" dst-port=53 in-interface-list=LAN protocol=tcp
add action=accept chain=router comment="accept udp ntp queries from lan" dst-port=123 in-interface-list=LAN protocol=tcp
add action=accept chain=router comment="accept SSH to router *trusted*" dst-port=22 log=yes log-prefix=test_log protocol=tcp src-address-list=TRUSTED
add action=accept chain=router comment="accept Winbox to router *trusted*" dst-port=8291 protocol=tcp src-address-list=TRUSTED
add action=accept chain=lan comment="accept access to mgmt01 *trusted*" dst-port=10022 in-interface-list=WAN protocol=tcp src-address-list=TRUSTED
/ip firewall nat
add action=masquerade chain=srcnat ipsec-policy=out,none out-interface-list=WAN
add action=dst-nat chain=dstnat dst-port=10022 in-interface-list=WAN protocol=tcp to-addresses=10.29.10.100 to-ports=10022

Routes


/ip route
add check-gateway=none disabled=no distance=1 dst-address=10.27.10.0/24 gateway=10.29.10.100 routing-table=main scope=30 suppress-hw-offload=no \
    target-scope=10
add disabled=no dst-address=172.19.255.0/24 gateway=10.29.10.100 routing-table=main suppress-hw-offload=no

mkx · Sat Dec 10, 2022 1:30 pm

So you indeed have routing triangle which upsets connection tracking machinery on RB5009.

Here's how it goes:

device A (from local LAN, let's say its IP address is 10.29.10.200) tries to communicate with device B (beyond VPN tunnel , let's say its IP address is 10.19.255.200) ... or the other way around, the effect is similar. Then you have main router in local LAN (let's call it RB) with IP address 10.29.10.1 and VPN gateway (let's call it VPNg) with IP address 10.29.10.100.
device A starts establishment of TCP connection by sending SYN packet towards device B
device A consults own routing tables and sees it needs to use RB as gateway. So device A passes packet to RB.
RB takes packet and sees it's not intended for itself.
connection tracking machinery (as one of early stages of stateful firewall) notes new connection (SYN packet is correct packet to start TCP connection). According to firewall filters it can be passed.
RB consults own routing tables and determines that next hop should be VPNg, so it passes packet to VPNg
packet arrives at VPNg. It sees it has to be pushed through VPN tunnel
packet arrives at device B. It replies with SYNACK packet (which is second stage of 3-step TCP handshake) through VPN tunnel
VPNg receives packet from VPN tunnel. It sees it's destined to device A
VPNg consults own routing tables and sees destination is member of same subnet, it thus passes packet to device A directly
note: packet bypasses RB and its connection tracking machinery!
device A receives SYNACK packet from device B. It then sends ACK packet -3rd stage of TCP handshake.
Similarly to step #3 it passes ACK packet to RB.
RB again performs steps #4 and #5. This time, though, it sees 3rd stage packet without seeing 2nd stage packet before (item #11 above). This makes packet invalid (according to connection state as percieved by connection tracking machinery)
due to firewall rule "drop invalid" it drops packet effectively blocking connection

Now, there are a few ways out:

accepting routing redirects
RB at step #6 above normally sends device A an ICMP message telling it that for this particular destination there's better next hop (VPNg).
Many OSes are configured to ignore such routing redirections (because they are easily used to hijack traffic from legitimate routers). Some are even (stupidly!) configured to drop/ignore all ICMP messages. If device A would accept this, then it would send further packets directly to VPNg thus bypassing RB also in "forward direction". Net effect would be RB seeing a few stale TCP connnections in "half established" state which would clear after TCP timeout.
I'm not sure if this solution solves the problem entirely, it coukd well be that those routing redirects are used "temporarily" and after expiry a fee packets would go the original path again. Those would be subject to RB firewall and probably get droped.
configuring LAN devices statically with routes towards VPN tunnel - not really feasible in larger environment
configuring RB not to track connections towards devices beyond VPN tunnel (a simple raw filter rule on RB would do), combined with (default) rule "accept untracked"
moving VPNg to separate IP subnet so that traffic between VPNg and rest of LAN always passes RB
performing SRC NAT on packet towards devices beyond VPN tunnel ... which would make all packet seem to originate from RB making VPNg to send replies to RB.
This solution has many drawbacks, so I included it here just because it's a solution to original problem never the less.

IMO solution #3 is pretty good one and easiest to implement ... drawback is that "forward traffic" still passes RB and consumes some resources. Possibly it uses more resources than solution #4, which allows to fasttrack traffic (solution #3 usually doesn't).

majestic · Sat Dec 10, 2022 1:42 pm

So you indeed have routing triangle which upsets connection tracking machinery on RB5009.

Here's how it goes:

device A (from local LAN, let's say its IP address is 10.29.10.200) tries to communicate with device B (beyond VPN tunnel , let's say its IP address is 10.19.255.200) ... or the other way around, the effect is similar. Then you have main router in local LAN (let's call it RB) with IP address 10.29.10.1 and VPN gateway (let's call it VPNg) with IP address 10.29.10.100.

device A starts establishment of TCP connection by sending SYN packet towards device B

device A consults own routing tables and sees it needs to use RB as gateway. So device A passes packet to RB.

RB takes packet and sees it's not intended for itself.

connection tracking machinery (as one of early stages of stateful firewall) notes new connection (SYN packet is correct packet to start TCP connection). According to firewall filters it can be passed.

RB consults own routing tables and determines that next hop should be VPNg, so it passes packet to VPNg

packet arrives at VPNg. It sees it has to be pushed through VPN tunnel

packet arrives at device B. It replies with SYNACK packet (which is second stage of 3-step TCP handshake) through VPN tunnel

VPNg receives packet from VPN tunnel. It sees it's destined to device A

VPNg consults own routing tables and sees destination is member of same subnet, it thus passes packet to device A directly

note: packet bypasses RB and its connection tracking machinery!

device A receives SYNACK packet from device B. It then sends ACK packet -3rd stage of TCP handshake.
Similarly to step #3 it passes ACK packet to RB.

RB again performs steps #4 and #5. This time, though, it sees 3rd stage packet without seeing 2nd stage packet before (item #11 above). This makes packet invalid (according to connection state as percieved by connection tracking machinery)

due to firewall rule "drop invalid" it drops packet effectively blocking connection

Now, there are a few ways out:

accepting routing redirects
RB at step #6 above normally sends device A an ICMP message telling it that for this particular destination there's better next hop (VPNg).
Many OSes are configured to ignore such routing redirections (because they are easily used to hijack traffic from legitimate routers). Some are even (stupidly!) configured to drop/ignore all ICMP messages. If device A would accept this, then it would send further packets directly to VPNg thus bypassing RB also in "forward direction". Net effect would be RB seeing a few stale TCP connnections in "half established" state which would clear after TCP timeout.
I'm not sure if this solution solves the problem entirely, it coukd well be that those routing redirects are used "temporarily" and after expiry a fee packets would go the original path again. Those would be subject to RB firewall and probably get droped.

configuring LAN devices statically with routes towards VPN tunnel - not really feasible in larger environment

configuring RB not to track connections towards devices beyond VPN tunnel (a simple raw filter rule on RB would do), combined with (default) rule "accept untracked"

moving VPNg to separate IP subnet so that traffic between VPNg and rest of LAN always passes RB

performing SRC NAT on packet towards devices beyond VPN tunnel ... which would make all packet seem to originate from RB making VPNg to send replies to RB.
This solution has many drawbacks, so I included it here just because it's a solution to original problem never the less.

IMO solution #3 is pretty good one and easiest to implement ... drawback is that "forward traffic" still passes RB and consumes some resources. Possibly it uses more resources than solution #4, which allows to fasttrack traffic (solution #3 usually doesn't).

Thank you so much @mkx for taking the time to explain this to me.

I have read all options and will go with your solution #3, it does seem like the easiest to implment and its scaleable.

I will go and have a play now and let you know final config for a quick once over if you woudlnt mind after its figured out.

Thanks again for your help.

Kind Regards,

Simon

Is missing connection-state=invalid hugely bad?

Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?

Re: Is missing connection-state=invalid hugely bad?