Community discussions

 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 2636
Joined: Mon Dec 04, 2017 9:19 pm

the magic of connection-state=new

Sat Feb 09, 2019 6:23 pm

This topic is here solely to offload the VLAN-related one from the firewall discussion.

@anav, connection-state=new is just one of the conditions which the packet must meet to match the rule. The logical operator among all rule conditions is always "and" (whereas if the condition says field=value1,value2,value3, it in most cases expands to (field=value1 or field=value2 or field=value3) - this is related to connection-state, addresses and ports, in exceptional cases, it expands to (field=value1 and field=value2 and field=value3) - I actually think the only case like this is the tcp-flags field.

The rest is more or less a matter of algorithmic programming. If you have

action=accept chain=forward connection-state=established,related
action=drop connection-state=invalid


at the beginning of your chain=forward of /ip firewall filter, any packet which got past the second rule must have one of two remaining possible values of connection-state - new or untracked. Those belonging to already established connections and those related to established connections have been accepted already by the first rule, and the invalid ones have been dropped by the second.

Now if we forget for a while about untracked, rule 3 and further are your "administrator's quest", made to handle only packets matching connection-state=new, in another words the initial (first) packets of each tracked connection. And as only packets matching connection-state=new can reach rule 3 and the following ones, it is not necessary to evaluate that condition in each of those rules as doing so consumes some CPU cycles. However, for clarity of reading, adding it there may be beneficial, and that's probably why @pcunite prefers to spend those few extra CPU cycles - only once per each new connection so not really much in total.

Of course, if your 3rd rule would contain only the condition connection-state=new and it would have action=accept, it would make the firewall wide open, but that's not the case there.

Once this becomes clear, we may spend a few words on connection-state=related and connection-state=untracked.
Last edited by sindy on Sat Feb 09, 2019 6:33 pm, edited 3 times in total.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 1652
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: the magic of connection-state=new

Sat Feb 09, 2019 6:55 pm

This topic is here solely to offload the VLAN-related one from the firewall discussion.

@anav, connection-state=new is just one of the conditions which the packet must meet to match the rule. The logical operator among all rule conditions is always "and" (whereas if the condition says field=value1,value2,value3, it in most cases expands to (field=value1 or field=value2 or field=value3) - this is related to connection-state, addresses and ports, in exceptional cases, it expands to (field=value1 and field=value2 and field=value3) - I actually think the only case like this is the tcp-flags field.

The rest is more or less a matter of algorithmic programming. If you have

action=accept chain=forward connection-state=established,related
action=drop connection-state=invalid


at the beginning of your chain=forward of /ip firewall filter, any packet which got past the second rule must have one of two remaining possible values of connection-state - new or untracked. Those belonging to already established connections and those related to established connections have been accepted already by the first rule, and the invalid ones have been dropped by the second.

Now if we forget for a while about untracked, rule 3 and further are your "administrator's quest", made to handle only packets matching connection-state=new, in another words the initial (first) packets of each tracked connection. And as only packets matching connection-state=new can reach rule 3 and the following ones, it is not necessary to evaluate that condition in each of those rules as doing so consumes some CPU cycles. However, for clarity of reading, adding it there may be beneficial, and that's probably why @pcunite prefers to spend those few extra CPU cycles - only once per each new connection so not really much in total.

Of course, if your 3rd rule would contain only the condition connection-state=new and it would have action=accept, it would make the firewall wide open, but that's not the case there.


Once this becomes clear, we may spend a few words on connection-state=related and connection-state=untracked.
That is where we differ on a number of aspects.

a. consuming a few cpu cycles to stick in a rule that is just going to confuse 1/2 the readers is really not worth it.
b. however as you point out, confirming my point all along, it would make the firewall wide open but at least pcunite only made it wide open for originating LAN packets, so the potential harm is limited.
d. Finally and to my clear point, I don't want new packets tested and passing through/bypass my firewall based on the following rule and in conversational style....

Hey packet, are you new? Well of course you must be because you didn't get teleported out of this filter chain by my first rule, so therefore I must not be already tracking you.
Well then, welcome new packet, oh I see you are coming from the LAN, thats great because, now you are free to go wherever you please as you have matched my new rule.
Escaping so soon sigh.........
I am sad because you will never get the benefit of trying my snakes and ladders fun of going down that LAN to WAN ladder, or LAN to VLAN ladder etc.......... now you are going wherever you please..................

In other words, what is stopping the new packet coming from the LAN going wherever it wants????
If you can answer this basic question then perhaps we will make progress.
 
sindy
Forum Guru
Forum Guru
Topic Author
Posts: 2636
Joined: Mon Dec 04, 2017 9:19 pm

Re: the magic of connection-state=new

Sat Feb 09, 2019 7:16 pm

welcome new packet, oh I see you are coming from the LAN, thats great because, now you are free to go wherever you please as you have matched my new rule.
Escaping so soon sigh.........
I am sad because you will never get the benefit of trying my snakes and ladders fun of going down that LAN to WAN ladder, or LAN to VLAN ladder etc.......... now you are going wherever you please..................

In other words, what is stopping the new packet coming from the LAN going wherever it wants????
If you can answer this basic question then perhaps we will make progress.
You're right, nothing stops it from going wherever it wants because the administrator (@pcunite) intentionally allows devices connected to the LAN to establish new connections wherever they wish to. In the very basic home configurations, it is normal that the firewall allows all devices on the (single) home network to get anywhere to the internet, and in the default settings even to the management interfaces of the Mikrotik itself. The default firewall only prevents devices on the WAN (internet) side of the router from establishing new connections to devices on the LAN side and to the router itself.

So the issue here is not whether connection-state=new is present in the 3rd rule or not, but whether the administrator requires that the initial packets of connections meet some other conditions to be let through or he doesn't. And as the only additional condition in this particular case is that the packet comes from LAN, he clearly doesn't.

If you segment your home network into several IP subnets and VLANs (having exactly one subnet in exactly one VLAN is the best practice but exceptions exist), you usually do so to set a different set of restrictions to each of them. And in that case, there will be different additional conditions in the rules permitting new connections for packets coming from each of those subnets/vlans - e.g. you won't allow devices from the subnet/VLAN intended for visitors to get anywhere else but to the internet, i.e. they won't be able to print on your printer or copy files from your NAS.
Instead of writing novels, post /export hide-sensitive. Use find&replace in your favourite text editor to systematically replace all occurrences of each public IP address potentially identifying you by a distinctive pattern such as my.public.ip.1.
 
anav
Forum Guru
Forum Guru
Posts: 1652
Joined: Sun Feb 18, 2018 11:28 pm
Location: Nova Scotia, Canada

Re: the magic of connection-state=new

Sat Feb 09, 2019 9:10 pm

I think we can close this case.
In any case, If I was confused by its inclusion, I am sure others will be as well, is my final point.
The parts you touched upon were interesting and germane.
In summary,
I still would never use his new rule for the following reasons.
a. I think allow rules should be clearly focussed, not forward to anything............
b. I think that any admin would not blindly allow native lan to vlans which he accomplishes/destroys with his rule.
(how does he intend to ensure that the native lan cannot access his vlans?)
c. There may be reason for an admin to be able to access vlans, but not all uses on the native LAN.
d. I don't think an admin would blindly allow a native vlan to access a dmz vlan for example or vice versa

So all in all, without much context the rule in my view is potentially dangerous and should be avoided.
 
User avatar
pcunite
Forum Veteran
Forum Veteran
Posts: 875
Joined: Sat May 25, 2013 5:13 am
Location: USA

Re: the magic of connection-state=new

Sat Feb 09, 2019 9:47 pm

Forgive me, I don't have time to properly discuss this topic in depth, at the moment. I'm working on publishing (just did a moment ago) some more configuration files (the single Access Point one).

However, to @anav, your opinion is valued and there maybe some merit to them. I'm not trying to teach firewalling, at this time. That subject is a very large one so I can't mix it in with VLAN. My firewall protects the LAN from WAN access, which all of us as good stewards of the MikroTik brand must endeavor to always illustrate.

But trying to protect the router itself from the LAN is not my concern at all, and I think people understand that. I don't want someone to use my config files and be locked out of their own equipment. To show router protection, LAN side and properly, is too large a topic. In a separate security topic, that type of pertinent information can be discussed.

So, I don't mind at all that you have an issue with the new keyword. I'm not finished with the VLAN topic. Perhaps if its too controversial we can remove it.

Who is online

Users browsing this forum: Baidu [Spider], Sob, vecernik87 and 12 guests