Hello all,
I have a problem with 2.9.48 with conntrack disabled as I am not doing NAT, just simple IP routing. However, it seems with conntrack disabled, RouterOS will not forward IP fragments. Here is an example of 2000 byte UDP payload (1500 + 548 with headers).
Conntrack disabled:
The highlighted area shows the problem. First, an SSH packet shows what normally happens, it arrives in ether1 and goes out wlan1. However the next packets are my 2000 byte UDP payload. Here you can see the packet and fragment arrives, but is not forwarded across wlan1.
Conntrack enabled:
Here is the same packet and fragment, but this time it is forwarded properly.
It is my understanding that connection tracking is not needed in order to handle fragments, since the source and destination information is included with each fragment. Why is RouterOS not forwarding unless I then turn on conntrack?
Connection tracking is not required to handle fragments provided the iptables state engine is not turned on. As there’s no way to turn the state engine off in RouterOS the end result is you need connection tracking to handle fragments.
we run 2 border routers with bgp and conn-track off … are you telling me that my borders haven’t been passing ip fragments for over 1.5 years ? i don’t totally disagree, but I’m a little confused as to why I didn’t find out this was breaking things earlier.
Most packets are sent DF (don’t fragment) so you will rarely see this as a problem in day to day operations, but some UDP applications send > MTU packets and rely on fragmentation for correct transmission. After installing a RouterOS system as my gateway, I found that several applications that used large UDP payloads broke and I determined the IP fragment forwarding to be the problem. It would be nice if disabling conntrack did actually disable it completely (unloaded modules, etc) so that normal IP fragment forwarding worked.
EDIT: It seems conntrack is limiting my throughput much more than I expected, I am only able to reach ~ 5.5mbps throughput over 200 tracked connections on an RB112. I was able to max out the wireless link (~10 mbps) before running into CPU issues with conntrack disabled, but having my UDP applications fail is not really an option either.
This is very interesting. I’d like to see what more people have to say about it, including if v3 is handling it any differently. I always make a habit of turning connection tracking off unless I an using NAT. I did not realize there could be consequences.
I’ll try and do some testing with v3 tomorrow. I hope it can be fixed, I really dislike losing half my performance to conntrack just to have fragment handled properly!
I work with Quake II code quite a bit, and master server communications are done in UDP with packets often exceeding MTU. In addition my Q2 client, R1Q2, supports fragmentation to allow greater amounts of data to be sent at once. Granted, for most people, IP fragments are probably not an issue, but for me this was quite unexpected behaviour to suddenly find my game no longer connects when behind MT device.
I will see about upgrading to v3 where possible, but there are still a few things in v3 that concern me.
THe reason why i ask is that i am a WISP and are having big problems with customers playing games like CS even if they have good pings and bw through the system they still lag a lot on these game servers and this could be the reason. On all routers in the net we have disabled connection tracking because we didn’t need it and this might be the reason why.
