Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 1999 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
    In the case of the IMAP packets, I was mistaken, these packets are originating from the mail server to the IMAP client. I am not sure if these are keep alive packets or if these are notification of mail, but they are not making it to the client because there is not a packet filter rule for the packets. The destination ports are not for any of the valid email protocols, since they are just high port numbers. Here are a couple of examples:


    10:43:00 Default DROP TCP 10.10.1.3 : 993 → 198.228.***.*** :8739 [ACK PSH FIN]
    10:43:13 Default DROP TCP 10.10.1.3 : 993 → 198.228.***.*** :29671 [ACK PSH FIN]


    I can create a packet filter rule which will enable these packets, but it will need to be a wildcard effectively since these ports are widely varying. This means that the mail server is able to send these packets out, but does open up the firewall a bit. I will go create a packet filter for those packets. In my own defense, the opposite is also true, when the IMAP server is located outside of my network. I have a few of these, but as I mentioned, I have turned off IDLE support for these since this problem comes up. Sorry for the confusion.

    Now, that leaves these packets that are inbound to my WAN address which are being dropped and appear to be valid packets such as the CTMAIL packets. I will take a look at the other packets and see where they are coming from and update my post.

    Mike
Reply
  • 0
    In the case of the IMAP packets, I was mistaken, these packets are originating from the mail server to the IMAP client. I am not sure if these are keep alive packets or if these are notification of mail, but they are not making it to the client because there is not a packet filter rule for the packets. The destination ports are not for any of the valid email protocols, since they are just high port numbers. Here are a couple of examples:


    10:43:00 Default DROP TCP 10.10.1.3 : 993 → 198.228.***.*** :8739 [ACK PSH FIN]
    10:43:13 Default DROP TCP 10.10.1.3 : 993 → 198.228.***.*** :29671 [ACK PSH FIN]


    I can create a packet filter rule which will enable these packets, but it will need to be a wildcard effectively since these ports are widely varying. This means that the mail server is able to send these packets out, but does open up the firewall a bit. I will go create a packet filter for those packets. In my own defense, the opposite is also true, when the IMAP server is located outside of my network. I have a few of these, but as I mentioned, I have turned off IDLE support for these since this problem comes up. Sorry for the confusion.

    Now, that leaves these packets that are inbound to my WAN address which are being dropped and appear to be valid packets such as the CTMAIL packets. I will take a look at the other packets and see where they are coming from and update my post.

    Mike
Children
No Data