Traffic from ec2-54-251-46-51.ap-southeast-1.compute.amazonaws.com

Jim, those are both srcport="80" - responses to HTTP requests from your network/UTM.  Can you find 54.251.46.87 in the Web Filtering log on the 28th?

Cheers - Bob

PS (EDIT an hour later): What do you get from the command line with

grep '_Ip' /etc/up2date/servers.sorted.rpmsave

Hi Bob,

When I ran the above command line the output was -bash: grep_Ip:  command not found. I looked at the log which showed two amazon servers 54.251.46.87 and 54.251.46.87 with identical activity both located in Sinagpore. The log has 194 entries all showing the same action. Singapore is one is a number of asian countries I have blocked. Is an exception needed? I am using UTM  9.409-9 which was loaded from an ISO.

Thanks,

Jim 

I would have thought that the connection tracker would have allowed responses back from a device in a blocked country (Singapore) to which a request was sent.  As it is, it appears that the response takes long enough that conntrack believes the connection was closed.  From the command line, you can see what the timeouts are:

cc get packetfilter timeouts

I expect that one of the lines will be "ip_conntrack_tcp_timeout_fin_wait" => 120,

I'm guessing that that might be the value in question, and you'll want to set it back to the default value once your test is done.  To set it to 300,

cc set packetfilter timeouts ip_conntrack_tcp_timeout_fin_wait 300

Does that cause the packets to no be blocked?

Cheers - Bob

Hi Bob,

The conntrack tcp time out was at 120. I reset it to 300, so now a wait and see. Thank you fot you help

Thanks,

Jim

Hi Bob,

I received exactly the same log entries from the Singapore servers. I wll either remove Singapoer from the group of blocked countries or try to create an exemption for those amazon servers.

Thanks,

Jim

You know, Jim, I never use the "All" option in Country Blocking, always just "From" because of situations like this.  Were you using "All" to block Singapore?  If you had been, I would have expected that the request would have been blocked, so my guess was incorrect as to which timeout is involved here.  You might open a case with Sophos Support and let us know what they say.

Cheers - Bob

Hi Bob,

Only from Singapore was blocked. I changed the rule for Singapore to off. Hopefully it solves the issue. Thank you for your help.

Thanks,

Jim

Hi Scott,

If you refer the link for the packetfilter logfiles here, the id=60019 in the logs has the reason "License Usage Exceeded (Active IPs) - LOG and DROP".

Hope that helps.

Jim, Sachin's last comment made me go back and look at the log lines you included in your first post.  In fact, those appear to be packets that the Singapore server sent back after conntrack thought the connection was complete (srcport="80").  Normally, they would have been a default drop, but Country Blocking caught them before they could be dropped by default.

In fact, those dropped FIN ACK packets were not a problem, and you could go back to your old CB setup as far as Singapore is concerned.

Cheers - Bob

Hello Sachin,

Thank you for your help and feed back and the link discribing the loggin identifers. Once I turned off the rule for Singapore in country blocking the issue disappeared completely.

Thanks,

Jim