Hi,

For some time I know that the RouterOS is not able to handle fragmented packets when connection traffic is disabled and any firewall rule used. We have several thousands of MT boxes installed and now it looks we need to solve the problem definitively. When we created the scripts to configure each new unit we decided to disable connection tracking (to reduce CPU load significantly). And we use some kind of firewall (to prevent clients to flood the network with inappropriate IPs, to block intruders to connects to the MT box, etc).
There are some customers which runs their own VPNs (Windows/cisco PIX based VPNs etc) and in some cases the customers are not able to establish VPN sessions (the reason is known for us - due to lower MTU of the VPN channel there are fragmented packets from these clients and MT box forwards only the first fragment)
The solution is simple - turn on the damned connection tracking module. But I would like prefer to don't use it.

Interesting/strabne thing on the whole problem is that having a MT box with disabled connection tracking and non-empty firewall rules doesn't mean in all cases that the fragmented traffics will not pass through. It is just a condition which must be met but it cause the problem only in some cases. We have customers whose VPN worked seamleslly for long months and then suddenly it stopped to work. Sometimes a restart/upgrade of MT box caused the VPN works again (for some time).
There are plenty of MT boxes in our network which respond to long pings and many of others (the same settings/ RouterOS version,...) which don't.

So I suspect there is something which causes that the MT box with enabled connection tracking and non empty firewall is able to work properly. And it would be fine if someone from Mikrotik could say what it is and then it would be possible to change the firmware to work fine in all cases not on random basis.

For example - a routerboard running 2.9.49 (but older releases behave the same way) with disabled connection tracking and non-empty firewall doesn;r respond to ping if long data are sent. But if I disable all the firewall rules the MT starts to respond. The strange thing is it is still sending ICMP replies even if I enable the firewall rules (at least for some time)... Then if you restart the box it will respond to short pings only again...
The firewall rules used in this experiment were rather simple. One accept/log line is enough

I have tried to use 'Ip Fragment' from 'Extra' options of the firewall rule settings but it didn't work. If the MT ignores the fragments it looks like them newer reach the rules....

Thanks
D. Toman

Hi,

For some time I know that the RouterOS is not able to handle fragmented packets when connection traffic is disabled and any firewall rule used. We have several thousands of MT boxes installed and now it looks we need to solve the problem definitively. When we created the scripts to configure each new unit we decided to disable connection tracking (to reduce CPU load significantly). And we use some kind of firewall (to prevent clients to flood the network with inappropriate IPs, to block intruders to connects to the MT box, etc).
There are some customers which runs their own VPNs (Windows/cisco PIX based VPNs etc) and in some cases the customers are not able to establish VPN sessions (the reason is known for us - due to lower MTU of the VPN channel there are fragmented packets from these clients and MT box forwards only the first fragment)
The solution is simple - turn on the damned connection tracking module. But I would like prefer to don't use it.

Interesting/strabne thing on the whole problem is that having a MT box with disabled connection tracking and non-empty firewall rules doesn't mean in all cases that the fragmented traffics will not pass through. It is just a condition which must be met but it cause the problem only in some cases. We have customers whose VPN worked seamleslly for long months and then suddenly it stopped to work. Sometimes a restart/upgrade of MT box caused the VPN works again (for some time).
There are plenty of MT boxes in our network which respond to long pings and many of others (the same settings/ RouterOS version,...) which don't.

So I suspect there is something which causes that the MT box with enabled connection tracking and non empty firewall is able to work properly. And it would be fine if someone from Mikrotik could say what it is and then it would be possible to change the firmware to work fine in all cases not on random basis.

For example - a routerboard running 2.9.49 (but older releases behave the same way) with disabled connection tracking and non-empty firewall doesn;r respond to ping if long data are sent. But if I disable all the firewall rules the MT starts to respond. The strange thing is it is still sending ICMP replies even if I enable the firewall rules (at least for some time)... Then if you restart the box it will respond to short pings only again...
The firewall rules used in this experiment were rather simple. One accept/log line is enough

I have tried to use 'Ip Fragment' from 'Extra' options of the firewall rule settings but it didn't work. If the MT ignores the fragments it looks like them newer reach the rules....

Thanks
D. Toman

Have you tried V3? Afaik V3 will handle fragtments much better.

Regards

Henrik

Have you tried V3? Afaik V3 will handle fragtments much better.

Regards

Henrik[/quote]

I didn't test the V3 behavior yet. I would like to have the thing working in 2.9.x - it is a lot of work for us to migrate all the stations to 3.0 (mainly because we developed some large scripts and V3 script language is incompatible with the older one). I saw no Mikrotik's proclamation that the V3 does include some changes related to fragmented packets. Maybe someone from Mikrotik would like to write if there is a chance the V3 is able to handle fragmented traffic even with disabled connection tracking ?

Regards
Dalibor Toman

for what its worth, remember V3 is based on linux 2.6 kernel which is just so much better than linux 2.4, in so many ways....

conntrack is a kernel function (under netfilter), so its highly likely to work better under V3.

I am faced with the same problem of upgrading thousands of routers to V3, but I know its inevitable.

j