IMAP 14300
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Plusnet Community
- :
- Forum
- :
- Help with my Plusnet services
- :
- :
- IMAP 14300
Re: IMAP 14300
03-06-2016 5:11 PM - edited 03-06-2016 5:12 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I'm not sure that your idea of making a rule for these packets and dumping them in an unmonitored firewall chain would work, because this issue is with packets which are arriving unexpected to NAT, BUT the same looking packets might also exist which are expected by NAT. Therefore your idea to re-route all of them might break your IMAP connectivity.
However, if @bobpullen is suggesting that these <1430?> port packets should only exist internally between the Plusnet email servers and the load-balancers, and therefore should never reach external customers, then maybe you idea could work.
Perhaps @bobpullen could clarify this detail for you ?
Re: IMAP 14300
06-06-2016 11:28 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@Anonymous wrote:
However, if @bobpullen is suggesting that these <1430?> port packets should only exist internally between the Plusnet email servers and the load-balancers, and therefore should never reach external customers, then maybe you idea could work.
That's my understanding, but then again our load balancer config isn't really my forté. I'll seek clarification. The fact that the traffic can be dropped with seemingly little impact on IMAP performance does suggest that it's spurious in nature though
Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵
Re: IMAP 14300
06-06-2016 11:37 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I agree !
The presence of these apparently spurious packets has no impact on the functionality of (my) IMAP connections with the Plusnet email servers, and I've been keeping an eye on this for several years.
I only had to do something because, initially I thought I was doing something wrong (like you do !), but my real problem with it was that my firewall logs were overflowing with this junk, which made analyzing the firewall history for other issues almost impossible because I couldn't see the wood for the trees.
Thanks for taking the time to reply.
Re: IMAP 14300
06-06-2016 11:51 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Just a thought, but is this behaviour seen when collecting email using POP3? I'm wondering if we might be dealing with IMAP IDLE status updates or something like that.
@bobpullen wrote:
Thanks @Anonymous, saves me a job trying to replicate the 'issue'.
@Anonymous wrote:
It was assumed to be a problem with the Plusnet load-balancers - which of course Plusnet never resolved.
Which is interesting because we replaced those load balancers in April.
Turns out the collection servers aren't behind the new load balancers yet.
Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵
Re: IMAP 14300
06-06-2016 7:23 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@bobpullen wrote:
Just a thought, but is this behaviour seen when collecting email using POP3?
I haven't used POP3 for nearly ten years, however I do happen to have a 'spare' PC with no currently installed email client, on which I could relatively easily setup a test POP3 mailbox, to run in isolation from anything currently running IMAP.
I should be able to set for it polling for new mail every few seconds - to create a lot of POP3 traffic and increase the chances of capturing unwanted packets.
Leave it with me, and I'll try to get something running in the next few days !
@bobpullen, do you happen to know whether POP3 uses the same port <14301> (on Force9) as IMAP ?.
It is just that if its different then I can try this sooner, because otherwise I have to wait until everyone is out of the house, then find all their devices using IMAP to switch off, before I could disable my firewall rule masking the rogue <14301> packets, to be able to look for anything unexpected.
Re: IMAP 14300
06-06-2016 8:15 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@Anonymous wrote:
@bobpullen, do you happen to know whether POP3 uses the same port <14301> (on Force9) as IMAP ?.
It is just that if its different then I can try this sooner, because otherwise I have to wait until everyone is out of the house, then find all their devices using IMAP to switch off, before I could disable my firewall rule masking the rogue <14301> packets, to be able to look for anything unexpected.
This is just a guess based on the protocol port number, but since POP3 uses port 110 one might expect the collection servers to be using 11001 (for Force9).
Re: IMAP 14300
06-06-2016 10:07 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵
Re: IMAP 14300
07-06-2016 12:02 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@bobpullen, I have setup a new Force9 mailbox, configured my 'spare' PC with the latest Thunderbird email client running on Ubuntu desktop v14.04-4, and have successfully got it sending email by SMTP and receiving using POP3.
I have sent a handful of emails from this test account, via the Force9 SMTP, and then POP3 fetches back to itself.
I also sat for about three minutes rapidly hitting the fetch mail button, to generate POP3 traffic.
My firewall rules are still configured to mask spurious packets on port <14301>, and the firewall logs have NOT shown ANY unexpected packets from the Force9 email servers, during this brief test.
While not an exhaustive test, I would have expected to see something in the firewall log if there was anything untoward happening.
Note that during this test, my firewall wouldn't have reported anything unexpected arriving on port <14301>, which I can't test for until everyone at home goes out for a while and I can switch their IMAP devices off.
I will keep this setup for the next couple of weeks, as the machine is in the process of hardware upgrades which will take a little while. I will also repeat the tests tomorrow for a longer period to see whether there are other factors involved. I will also try removing the port <14301> mask when I have the opportunity.
My initial observation is that using Plusnet POP3 doesn't seem to suffer spurious packets in the same way as Plusnet IMAP.
If you have any suggestions for additional testing methods, then I will see what I can do to help.
Re: IMAP 14300
07-06-2016 10:49 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Thanks for that @Anonymous, very helpful indeed.
Early days but seems like it's something specific to IMAP then.
If your machine initiates a connection towards the mail server VIP - i.e. the IP's that imap.force9.net resolves to - then when the back-end server replies - i.e. those with the 84.93.0.0/16 addresses - I'd expect the load-balancer to replace the real server IP with the VIP address.
If the server initiates an 'unsolicited' connection, then I'm told the load-balancers won’t do anything special and will route the traffic on without hiding the server’s real IP address. I'm not sure that entirely explains what's being seen though, because the TCP packets that are being blocked are ACK packets suggesting they're in response to requests that originated from your machine.
Do the packets coincide with the approximate timestamps of emails you receive?
Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵
Re: IMAP 14300
07-06-2016 11:40 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I have had my 'test' PC running POP3 since 09:00 this morning, and I haven't seen any blocked (non port <14301>) firewall entries.
I have temporarily disabled my port <14301> masking rule, and I am seeing blocked <14301> entries, but that probably means there is a machine using IMAP in the house, and there are other people currently using the internet. I'm waiting to see whether the <14301> entries disappear, when they are doing something else.
Yes, I understand the dilemma about the ACKs and whether they were in response to something I sent.
However, if it was something broken at my end, then I would have expected to see similar unexpected ACKs coming from the non-Plusnet IMAP server mailboxes which are being polled by the same email client.
Do the packets coincide with the approximate timestamps of emails you receive?
That would be difficult to prove, with at least eight different PCs running and using IMAP, and the household receiving more than a thousand emails every day. However my gut feeling would be no.
I'm going to think about whether it is possible to wireshark my WAN (PPPoE) connection, and get my head around whether I can intercept and log all outgoing and incoming Plusnet email packets (for ANY port numbers, on 20 servers), then see if I can match the NAT outgoing port numbers with the incoming ACKs. As I say, I don't know whether I can achieve this, and I've not looked at the current packet capture ability of pfSense - as recently the entire of pfSense was rewritten, I've only had the new version installed for a week or two, and anything could have changed. But I will take a look when I get some quiet time when I can think this through.
Re: IMAP 14300
07-06-2016 12:38 PM - edited 07-06-2016 12:49 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
WRT "The presence of these apparently spurious packets has no impact on the functionality of (my) IMAP connections with the Plusnet email servers", it did for me previously as v3.0 of Smoothwall had an add-on which added an IP to a block list for X days if it "banged on the door uninvited" more than Y times in Z minutes. The above behaviour meant that PlusNet email servers were continuously put on the "naughty step". I had tried to put the IPs in a whitelist but thought there were lots of them so gave up.
V3.1 of SmoothWall doesn't have that Active IP block add-on (at the moment.. )..it was one of it's attractions for me ..
Re: IMAP 14300
07-06-2016 4:29 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Doh! that effect on an active-IP-blocker would be a nuisance !
Would the Plusnet email servers still get flagged (for blocking) if you used firewall rules to 'allow' the firewall to pass the unwanted packets, rather than trying to overcome the problem properly with a whitelist as you tried ?.
I'm assuming the active-IP-blocker takes it's input from the firewall logs and sets rules on what had been repeatedly blocked ?.
Re: IMAP 14300
07-06-2016 5:34 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
@bobpullen, having run my 'test' PC doing POP3 activity for eight hours, and removing my port <14301> masking rule, and finally switching off all PCs and phones using IMAP.
I am as certain as I can be, that POP3 does NOT create ANY spurious packets in the same way as Plusnet IMAP does.
I will look at doing the wireshark monitoring of IMAP traffic another day.
Not wishing to sound like a broken record, but these unwanted packets bouncing off IPv4 NAT wouldn't be a problem (to my router) if you enabled IPv6 at your end.
Also doing a wireshark on a PC to capture IPV6 IMAP traffic, whilst also running an email client, would be a hell of a lot easier than trying to setup a wireshark monitor on a router's PPPoE WAN interface when the packets have been translated by IPv4 NAT.
I'm still determined to give the IPv4 WAN monitoring a try, as I like a challenge, and I will probably learn something new !
Re: IMAP 14300
07-06-2016 10:02 PM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
I've done it !
Is Bob interested in a packet capture trace on my router's WAN (PPPoE) interface, showing the Plusnet IMAP email servers going from working normally to chucking out spurious packets ?
Re: IMAP 14300
08-06-2016 9:54 AM
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Report to Moderator
Absolutely!
Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page