IPS issues with MEGAsync

jakoch · 3 April 2022 13:40

This post is a FYI.
I have found that enabling the Drop Hostile option broke the connections to the MEGAsync servers located in Canada. A review of the firewall logs showed the MEGAsync servers being dropped with DROP_NEWNOTSYN designation. Turning off “Drop packets from …” and a reboot allowed MEGAsync to work properly again. However, the IPs are still being dropped DROP_NEWNOTSYN but less frequently.

After enabling the Drop Hostile option and rebooting again MEGAsync works as expected.

pmueller · 3 April 2022 13:58

Hi,

could you please post the IP address(es) in question here?

DROP_NEWNOTSYN has nothing to do with DROP_HOSTILE. If you see such firewall hits, this can happen if IPFire was rebooted (so it starts with an empty connection tracking table, whereas a client behind it still maintains a network connection as being successfully established), or it indicates a broken/RFC-ignorant network device or application.

Well, it was not “drop hostile” then, otherwise the application would have stopped working. Or did I misunderstand you?

Thanks, and best regards,
Peter Müller

jakoch · 3 April 2022 14:20

The IP addresses were 162.208.16.35, 36, and 37.
A review of the logs shows that all issues are cleared up.

As you say it does not appear to be a Drop Hostile issue, just purely coincidental.

pmueller · 3 April 2022 14:56

Hi,

this is odd, as they are not marked as being hostile in the location database:

[root@maverick ~]# location version
Sat, 02 Apr 2022 05:55:09 GMT
[root@maverick ~]# location lookup 162.208.16.35
162.208.16.35:
  Network                 : 162.208.16.0/24
  Country                 : Canada
  Autonomous System       : AS205809 - MEGA Cloud Services Limited

(That output covers the entire /24, so querying one IP address is sufficient. )

Well, I really don’t see the connection to the “drop hostile” feature here, but will be happy to investigate further, if necessary. Could you please post the relevant log messages here, too? They are in /var/log/messages, and should contain DROP_HOSTILE as well as the Canadian IP addresses in question.

Thanks, and best regards,
Peter Müller

jakoch · 3 April 2022 15:48

There are close to 5000 records in the file. Non are DROP_HOSTILE. They are all marked DROP_NEWNTSYN. So obviously no connection with “Drop Hostile”.

[root@feta2 ~]# cat /var/log/messages | grep 162.208.16 | tail -n 20
Apr  3 09:39:25 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.101 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=18478 DF PROTO=TCP SPT=80 DPT=40508 WINDOW=6 RES=0x00 ACK URGP=0 
Apr  3 09:40:38 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=21714 DF PROTO=TCP SPT=80 DPT=56836 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:12:02 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45786 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:13:18 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45787 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:13:54 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11148 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:14:34 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45788 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:15:10 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11149 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:15:49 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45789 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:16:26 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11150 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:17:05 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45790 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:17:42 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11151 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:18:21 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45791 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:18:58 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11152 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:19:37 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45792 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:20:13 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11153 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:20:53 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45793 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:21:29 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11154 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:22:08 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.107 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=45794 DF PROTO=TCP SPT=80 DPT=56838 WINDOW=510 RES=0x00 ACK URGP=0 
Apr  3 10:22:45 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11155 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0 
Apr  3 10:24:01 feta2 kernel: DROP_NEWNOTSYN IN=red0 OUT= MAC=00:0d:b9:5a:41:87:00:c8:8b:db:d8:1a:08:00 SRC=162.208.16.108 DST=24.44.73.137 LEN=52 TOS=0x00 PREC=0x00 TTL=53 ID=11156 DF PROTO=TCP SPT=80 DPT=42240 WINDOW=8 RES=0x00 ACK URGP=0

jakoch · 9 April 2022 12:08

After some experimenting it turned out the issue and solution was the having the IPS enabled on Blue and Green networks. By turning off the monitoring of the Blue and Green networks the issue has gone away. I looked through the rule sets but could not ascertain which where the problematic rules. What I do know is that the issue was caused by the services’ connections being dropped with DROP_NEWNOTSYN in the logs.

pmueller · 10 April 2022 14:26

Hi,

this might be related to a bug in the Linux kernel connection tracking @ms spotted a while ago.

Upcoming Core Update 167 features an updated kernel with this patch included. No changelog is available yet (because it still needs to be proofread), but as soon as it is, you will get an e-mail from the project nevertheless.

If possible, it would be great if you could test this update, and report whether the problem still persists.

Thanks, and best regards,
Peter Müller

ms · 11 April 2022 07:50

I don’t believe these problems are related, but there is a chance that I am wrong.

It would be great to see if the kernel that is currently in testing fixes this problem already.

jakoch · 13 April 2022 19:07

Peter, I unfortunately do not have the facility to test the upgrade. I will however report back as soon as the production version is released.

jakoch · 30 April 2022 11:17

I have updated to Core 167. As a test I enabled IPS on Blue. Immediately MEGAsync was unable to upload or download changes. Once disabled on Blue the files synced. I will again read through the rule sets to see if I can find something that could be causing the problem.