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
    Hey Bob, thanks for the response. I just created the rule for outbound traffic with a source port defined as 993 and a destination of 1024:65535 and added it as a valid email protocol for the packet filter.

    Unfortunately, I can not do the reverse for servers located outside of the network. Since the packet comes into the gateway as IP:993 for the source and the WAN address[:P]ort for the destination, I have no idea which client to forward the packet to using a DNAT rule. So I will need to leave IDLE disabled for servers outside of the network. I think this would need to be solved by the gateway with a proxy for IMAP.

    BTW, those prefixes are the ones assigned by AT&T for the iPhone we have here in WA state. Just FYI.

    Mike
Reply
  • 0
    Hey Bob, thanks for the response. I just created the rule for outbound traffic with a source port defined as 993 and a destination of 1024:65535 and added it as a valid email protocol for the packet filter.

    Unfortunately, I can not do the reverse for servers located outside of the network. Since the packet comes into the gateway as IP:993 for the source and the WAN address[:P]ort for the destination, I have no idea which client to forward the packet to using a DNAT rule. So I will need to leave IDLE disabled for servers outside of the network. I think this would need to be solved by the gateway with a proxy for IMAP.

    BTW, those prefixes are the ones assigned by AT&T for the iPhone we have here in WA state. Just FYI.

    Mike
Children
No Data