Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 3 subscribers
  • Views 1998 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.
  • 0
    Hi,
    with the imap packets that are being blocked, which device originates the packet?

    Does the packet come through as part of a mail transaction is it more of a keep alive?

    I suspect you will have to have a dnat rule allowing those packets through to the server if they are just keep alive type messages.

    Ian M[:)]
  • 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
  • 0
    Mike, you would need to define something like "IMAP-SSL-Response"="993->1024:65535" - did you try that?  With AT&T, the iPhone gets IPs in 166.128.0.0/9.

    Cheers - Bob
  • 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
  • 0
    OK, getting back to my main issue in this thread, here are some packets I do not understand. I have a Web Application Rule setup to allow SSL access to the mail server for webmail. I just had a dump of 50+ messages into the live log that look like this:


    11:23:42 Default DROP TCP 10.10.1.3 : 443 → 10.10.1.1 : 45117 [RST]  len=40 ttl=64 tos=0x00
    11:23:42 Default DROP TCP 10.10.1.3 : 443 → 10.10.1.1 : 45142 [RST]  len=40 ttl=64 tos=0x00


    These look like a lost connection between the client on the outside of the firewall and the internal mail server. Otherwise, it makes not sense why the server would be responding to the 10.10.1.1 (firewall) address with a packet. Thoughts?

    I have had users complain about webmail sometimes not working. Other times, it appears to work fine. Seeing these dropped packets, might explain why it stops working from time to time. This again is not something I can fix with a rule since I do not know the client to send these packets.

    UPDATE: So I just checked with the person who was using webmail at this time and they said that it became unresponsive and caused internet explorer to be slow. So it does seem to be the source of the problems people have with webmail (at least in this case).

    Mike
  • 0
    Interestingly, this problem seems to be a lot worse if there is a mac running Snow Leopard in the network. I had a guest for the holidays and noticed we were dropping thousands of packets and traced 85% of them to this one mac. 

    They came in two forms, inbound packets destined for the mac's IP or packets destined for the gateway all from port 80. This was particularly bad when visiting the Facebook site, but appears to be web browsing in general.

    I am not sure sure what is going on here, but I am sure it is not good.

    Mike
  • 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