[opensuse] incoming tcp connections with ECN
I am having a bit of an issue with a customer and their inbound traffic to us. It's authenticated SMTP on port 587 with TLS. For whatever reason, they're trying to negotiate ECN. The receiving systems are somewhat backlevel/due-for-update, kernel 2.6 with /proc/sys/net/ipv4/tcp_ecn = 0 by default. Newer systems have '2': 0 – disable ECN and neither initiate nor accept it 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections When /proc/sys/net/ipv4/tcp_ecn is 0, incoming connections appear to be simply ignored, even when the sending host switched off ECN after having tried with ECN. The solution seems to be to set /proc/sys/net/ipv4/tcp_ecn = 2. The question is - are there any other effects? -- Per Jessen, Zürich (21.2°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Per Jessen wrote:
I am having a bit of an issue with a customer and their inbound traffic to us. It's authenticated SMTP on port 587 with TLS. For whatever reason, they're trying to negotiate ECN. The receiving systems are somewhat backlevel/due-for-update, kernel 2.6 with /proc/sys/net/ipv4/tcp_ecn = 0 by default. Newer systems have '2':
0 – disable ECN and neither initiate nor accept it 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections
When /proc/sys/net/ipv4/tcp_ecn is 0, incoming connections appear to be simply ignored, even when the sending host switched off ECN after having tried with ECN. The solution seems to be to set /proc/sys/net/ipv4/tcp_ecn = 2.
An alternative would be to use iptables to remove the two ECN bits, I haven't tried this yet. Any opinions? -- Per Jessen, Zürich (21.5°C) http://www.dns24.ch/ - your free DNS host, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 30 May 2016 18:25, Per Jessen wrote:
Per Jessen wrote:
I am having a bit of an issue with a customer and their inbound traffic to us. It's authenticated SMTP on port 587 with TLS. For whatever reason, they're trying to negotiate ECN. The receiving systems are somewhat backlevel/due-for-update, kernel 2.6 with /proc/sys/net/ipv4/tcp_ecn = 0 by default. Newer systems have '2':
0 – disable ECN and neither initiate nor accept it 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections
When /proc/sys/net/ipv4/tcp_ecn is 0, incoming connections appear to be simply ignored, even when the sending host switched off ECN after having tried with ECN. The solution seems to be to set /proc/sys/net/ipv4/tcp_ecn = 2.
An alternative would be to use iptables to remove the two ECN bits, I haven't tried this yet.
Any opinions?
Well, if your kernel is fully able to handle ECN, it is a nice to have feature, thus "tcp_ecn = 2" is the most helpful in the reality of the now. If your kernel is NOT able to handle ECN fully, stripping out the ECN-bit is the most wise and efficent way to handle the situation. Here in your case, if the system works well with "tcp_ecn = 2", it would be your best option, for the other cases, stripping out the ECN bits will be the most helpful. - Yamaban. PS: Info for the interested: https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
Yamaban wrote:
On Mon, 30 May 2016 18:25, Per Jessen wrote:
Per Jessen wrote:
I am having a bit of an issue with a customer and their inbound traffic to us. It's authenticated SMTP on port 587 with TLS. For whatever reason, they're trying to negotiate ECN. The receiving systems are somewhat backlevel/due-for-update, kernel 2.6 with /proc/sys/net/ipv4/tcp_ecn = 0 by default. Newer systems have '2':
0 – disable ECN and neither initiate nor accept it 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections
When /proc/sys/net/ipv4/tcp_ecn is 0, incoming connections appear to be simply ignored, even when the sending host switched off ECN after having tried with ECN. The solution seems to be to set /proc/sys/net/ipv4/tcp_ecn = 2.
An alternative would be to use iptables to remove the two ECN bits, I haven't tried this yet.
Any opinions?
Well, if your kernel is fully able to handle ECN, it is a nice to have feature, thus "tcp_ecn = 2" is the most helpful in the reality of the now.
If your kernel is NOT able to handle ECN fully, stripping out the ECN-bit is the most wise and efficent way to handle the situation.
Here in your case, if the system works well with "tcp_ecn = 2", it would be your best option, for the other cases, stripping out the ECN bits will be the most helpful.
Thanks Yamaban, most helpful! Do you also happen to know how I determine if the kernel is capable? If that cannot be or is difficult to determine, I presume it is best to just strip the ECN bits? The mechanism seems to be mostly superfluous these days anyway. It is the first time ever in ten years I have had this issue.
PS: Info for the interested: https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
I've been reading that backwards and forwards all day, it's not one of the better wikipedia articles. -- Per Jessen, Zürich (18.2°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On Mon, 30 May 2016 20:57, Per Jessen wrote:
Yamaban wrote:
On Mon, 30 May 2016 18:25, Per Jessen wrote:
Per Jessen wrote:
I am having a bit of an issue with a customer and their inbound traffic to us. It's authenticated SMTP on port 587 with TLS. For whatever reason, they're trying to negotiate ECN. The receiving systems are somewhat backlevel/due-for-update, kernel 2.6 with /proc/sys/net/ipv4/tcp_ecn = 0 by default. Newer systems have '2':
0 – disable ECN and neither initiate nor accept it 1 – enable ECN when requested by incoming connections, and also request ECN on outgoing connection attempts 2 – (default) enable ECN when requested by incoming connections, but do not request ECN on outgoing connections
When /proc/sys/net/ipv4/tcp_ecn is 0, incoming connections appear to be simply ignored, even when the sending host switched off ECN after having tried with ECN. The solution seems to be to set /proc/sys/net/ipv4/tcp_ecn = 2.
An alternative would be to use iptables to remove the two ECN bits, I haven't tried this yet.
Any opinions?
Well, if your kernel is fully able to handle ECN, it is a nice to have feature, thus "tcp_ecn = 2" is the most helpful in the reality of the now.
If your kernel is NOT able to handle ECN fully, stripping out the ECN-bit is the most wise and efficent way to handle the situation.
Here in your case, if the system works well with "tcp_ecn = 2", it would be your best option, for the other cases, stripping out the ECN bits will be the most helpful.
Thanks Yamaban, most helpful! Do you also happen to know how I determine if the kernel is capable? If that cannot be or is difficult to determine, I presume it is best to just strip the ECN bits? The mechanism seems to be mostly superfluous these days anyway. It is the first time ever in ten years I have had this issue.
Oh, how did I handle that? (long time ago....) - First, try setting "tcp_ecn = 2" (sysctl net.ipv4.tcp_ecn=2) - Are new incomming connection handled correctly ? (accepted, regardless of ECN bits) Yes? -- Then OK, you are done, please, add the "net.ipv4.tcp_ecn=2" to your config in /etc/sysctl* - Still dropped or rejected connections? Invest the work in the filter. Last time I had to do the filter work was a early 2.6 kernel in a mostly 2.4 kernel environment, and many of the routers couldn't handle ECN then. The 2.6 series supports all three values, BUT exactly how it handles option (0/zero) is not consitent over the 2.6 series. Thus the errors you see (not to allow non ECN conn. after denied ECN conn)
PS: Info for the interested: https://en.wikipedia.org/wiki/Explicit_Congestion_Notification
I've been reading that backwards and forwards all day, it's not one of the better wikipedia articles.
I know, it's not intuitive at all. I just use it as entry point / links collection (at the bottom). - Yamaban.
Yamaban wrote:
On Mon, 30 May 2016 20:57, Per Jessen wrote:
Thanks Yamaban, most helpful! Do you also happen to know how I determine if the kernel is capable? If that cannot be or is difficult to determine, I presume it is best to just strip the ECN bits? The mechanism seems to be mostly superfluous these days anyway. It is the first time ever in ten years I have had this issue.
Oh, how did I handle that? (long time ago....)
- First, try setting "tcp_ecn = 2" (sysctl net.ipv4.tcp_ecn=2)
- Are new incomming connection handled correctly ? (accepted, regardless of ECN bits) Yes? -- Then OK, you are done, please, add the "net.ipv4.tcp_ecn=2" to your config in /etc/sysctl*
Thanks, that's pretty much as I thought. It's been working with tcp_ecn=2 since last night.
- Still dropped or rejected connections? Invest the work in the filter.
I think I'll try that out today, it's just a single iptables directive. -- Per Jessen, Zürich (15.6°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (2)
-
Per Jessen -
Yamaban