cancel
Showing results for 
Search instead for 
Did you mean: 

IMAP 14300

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

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 ?

Community Gaffer
Community Gaffer
Posts: 13,554
Thanks: 1,243
Fixes: 102
Registered: ‎04-04-2007

Re: IMAP 14300


Nibiru 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 Undecided

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

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.  Smiley

Community Gaffer
Community Gaffer
Posts: 13,554
Thanks: 1,243
Fixes: 102
Registered: ‎04-04-2007

Re: IMAP 14300

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 @Nibiru, saves me a job trying to replicate the 'issue'.

Nibiru 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 ⤵

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300


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 !  Wink

 

@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.

Superuser
Superuser
Posts: 9,888
Thanks: 1,252
Fixes: 71
Registered: ‎06-04-2007

Re: IMAP 14300


Nibiru 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).

David
Community Gaffer
Community Gaffer
Posts: 13,554
Thanks: 1,243
Fixes: 102
Registered: ‎04-04-2007

Re: IMAP 14300

@spraxyt is right, I think it will be 11000, 11001 or 11002 depending on the VISP.

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

@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.

 

Wink

Community Gaffer
Community Gaffer
Posts: 13,554
Thanks: 1,243
Fixes: 102
Registered: ‎04-04-2007

Re: IMAP 14300

Thanks for that @Nibiru, 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 ⤵

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

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.

Simon
Grafter
Posts: 53
Thanks: 2
Registered: ‎01-08-2007

Re: IMAP 14300

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.. Sad )..it was one of it's attractions for me ..

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

Doh! that effect on an active-IP-blocker would be a nuisance !  Sad

 

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 ?.

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

@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.  Tongue

 

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.  Roll eyes

 

I'm still determined to give the IPv4 WAN monitoring a try, as I like a challenge, and I will probably learn something new !  Wink

Community Veteran
Posts: 5,472
Thanks: 292
Fixes: 4
Registered: ‎11-08-2007

Re: IMAP 14300

I've done it !  Cool

 

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 ?

 

Cool smiley

Community Gaffer
Community Gaffer
Posts: 13,554
Thanks: 1,243
Fixes: 102
Registered: ‎04-04-2007

Re: IMAP 14300

Absolutely!

Bob Pullen
Plusnet Product Team
If I've been helpful then please give thanks ⤵