UTM denying return traffic from RDS/HCSS cloud provider

Hi Timothy and welcome to the UTM Community!

What do you learn from doing #1 in Rulz (last updated 2019-04-17)?

If you still need help, show us a related line from the log file.

Cheers - Bob

Bob, 

Thanks for the reply. I checked the UDP flooding, and it wasn't enabled. hHat didn't fix the problem.

Here is one of the logs: 

2020:05:06-05:45:08 fw-01 ulogd[26891]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth4" srcmac="02:02:33:40:53:95" dstmac="00:1a:8c:51:42:7e" srcip="y.y.y.y" dstip="x.x.x.x" proto="17" length="105" tos="0x00" prec="0x00" ttl="118" srcport="3391" dstport="56332"

When these denies appear in my firewall logs, my end users are complaining about disruptions to their remote desktop session to the cloud provided. 

I do not have a DNAT with this dynamic ports allowed. Could that be my issue? 

This is just a guess, Timothy - I wonder if your ISP or the RDS/HCSS cloud provider is having overload problems.

I say that because this kind of thing is usually caused by the connection tracker thinking that a conversation has ended.  The normal value is 30, but try the following as root at the command line:

cc set packetfilter timeouts ip_conntrack_udp_timeout 150

If you aren't comfortable doing that, you could get a ticket opened with Sophos Support and they could try that for you.

Any luck with that?

Cheers - Bob

This is just a guess, Timothy - I wonder if your ISP or the RDS/HCSS cloud provider is having overload problems.

I say that because this kind of thing is usually caused by the connection tracker thinking that a conversation has ended.  The normal value is 30, but try the following as root at the command line:

cc set packetfilter timeouts ip_conntrack_udp_timeout 150

If you aren't comfortable doing that, you could get a ticket opened with Sophos Support and they could try that for you.

Any luck with that?

Cheers - Bob

That makes sense, when running wireshark locally, I'm seeing successful two-way traffic similar to the traffic I provided above. The cloud provider app is essentially using dtls to communicate (udp/3391).

But, I'm seeing these same errors today (Sunday). The assumption is if it's a capacity issue, the volume of traffic for the cloud provider and ISP is significantly lower over the weekend than what it would be during a work week. Yes, the errors are less frequent today and yesterday than what they were on Friday. 

I will give it a try. 

naturally, It's hard to replicate the problem to see if it works right away ;) 

Thanks Bob

That didn't seem to work. I'll leave the timeout value to 150 seconds for now. 

I updated the inbound rule to include the ephermeral ports (49152:65535) for the destination port. 

The rule is exclusive to the provider's public IP (never changes). 

Lowers the posture of the firewall, and this will be temp, but I need to know if this is the issue. 

If that change in the inbound rule fixes this, I'm really confused.  Please get a case open with Sophos Support and see what they have to say about this.

Cheers - Bob