Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 1997 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

[BUG] 8.202 seems to "lose" masqueraded connections

mikeshappell
OK, I am not 100% clear on how to describe this, but here goes. Let me start with connections that are going to the gateway itself. It appears that the mail proxy uses Commtouch, I am guessing for anti-spam? I say this because I am seeing dropped packets associated with c2iprep1.ctmail.com, and some other mail related anti-spam sites. So far today, there have been 17:

c2iprep1.*ctmail.*com 17 2.71

I have managed to cleanup my firewall logs to the point that these stand out for me. Specifically, I was tracing a number of dropped packets by address back to their source and found this one, plus a couple of others. The fact that these seem to be related to anti-spam makes me think the gateway is not getting these.

Now, there are other packets that are being dropped that look like (cannot be sure, but hope someone can help) they are NAT sessions that are not making it back to the internal network. For example, I have an email server running in my network (I suppose that was obvious from the above information). I have twoiPhone clients outside of my network that access the server using IMAP SSL (993). I have a DNAT rule for IMAP since the gateway does not have a proxy for this protocol.

Regularly, I see inbound IMAP SSL (993) packets, source address is the iPhone, source port is 993 and the destination is some high numbered port at my external WAN address. I am going to guess that these are related to IMAP idle support. Why, because I had some internal clients using IMAP with idle enabled and got the some types of packets. Turning off idle for the internal clients made the dropped packets go away. I cannot turn off idle for the iPhone clients. Yet, I am not sure why the gateway is dropping them, unless they are just coming to long after the hole was opened. I have had 226 so far today for two clients.

Server - Mail 226 35.48

I would love to be able to fix these. Any information on why these issues are occurring and if this is in fact a BUG that will be resolved in a future release would be appreciated.

Mike


This thread was automatically locked due to age.
Parents
  • 0
    Hi, if you're seeing SYN packets dropped, then something is wrong.

    For RST and FIN/ACK's, they're usually caused by the fact that the client or server is trying to restore the tcp session long after the firewall has considered it to be expired.

    It's probably not worth worrying about, as the client should restart the connection automatically.

    Barry
Reply
  • 0
    Hi, if you're seeing SYN packets dropped, then something is wrong.

    For RST and FIN/ACK's, they're usually caused by the fact that the client or server is trying to restore the tcp session long after the firewall has considered it to be expired.

    It's probably not worth worrying about, as the client should restart the connection automatically.

    Barry
Children
No Data