cancel
Showing results for 
Search instead for 
Did you mean: 

IMAP 14300

Simon
Grafter
Posts: 64
Thanks: 3
Registered: ‎01-08-2007

IMAP 14300

Hello,
In the firewall logs of my SmoothWall I see frequent blocks on packets from PlusNet IMAP server on port 14300..
My Mail client is set to use an incoming IMAP server on port 143.
Use of the IMAP servers is sometimes sluggish.

My initial thought is that my initial outgoing IMAP request on 143 would be answered on 14300 but the reply is too slow coming and is disconnected from the request..

.. don't use PlusNet for internet connection now but when did this still happened.

Questions:
Can I do anything in smoothwall to help this?
Is this an IMAP thing?
Is this an IMAP thing specific to PlusNet?

TIA.
(P.S. Will post this on smoothwall as well.)

45 REPLIES 45
bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: IMAP 14300

Port 14300 is likely to be the 'real' port that is used between the load balancer and the mail collection servers. I'm not sure why you're seeing blocked packets originating from that port though.

What mail client are you using? Using Thunderbird, I can't see any inbound traffic originating from port 14300. I guess it could be getting blocked before it reaches my machine but I can't see anything in the router's firewall logs.

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

Simon
Grafter
Posts: 64
Thanks: 3
Registered: ‎01-08-2007

Re: IMAP 14300

... outlook 2016 (happened with prev. versions) Incoming server set to imap.plus.net (in more settings / advanced imap port is 143)

Maybe att. firewall log might shed light (or not Wink )

.. won't let me att. .txt Roll_eyes.. so pasted below.. .. nor be more than 50,000 chars Ticked_off

11:14:59 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=32189 DF PROTO=TCP SPT=14300 DPT=10810 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:30 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2814 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:31 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2816 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:31 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2817 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:32 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2818 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:34 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2819 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:39 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2820 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:16:47 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2821 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:05 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2822 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:09 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3084 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:09 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3086 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:10 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3087 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:12 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3088 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:17 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3089 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:25 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3090 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:40 Denied-by-filter:badtraffic src=84.93.238.132 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=2823 DF PROTO=TCP SPT=14300 DPT=3916 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:17:42 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3091 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:03 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51536 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:03 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51538 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:04 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51539 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:05 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51540 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:07 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51541 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:11 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51542 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:16 Denied-by-filter:badtraffic src=84.93.238.164 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=3092 DF PROTO=TCP SPT=14300 DPT=3805 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:18:19 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51543 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:19:06 Denied-by-filter:badtraffic src=84.93.238.136 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=51 ID=51545 DF PROTO=TCP SPT=14300 DPT=5170 WINDOW=115 RES=0x00 ACK PSH URGP=0
11:19:12 Denied-by-filter:badtraffic src=84.93.238.201 DST=my.ip.ad.rs LEN=76 TOS=0x00 PREC=0x00 TTL=50 ID=48525 DF PROTO=TCP SPT=14300 DPT=9278 WINDOW=115 RES=0x00 ACK PSH URGP=0

 

Soz..

 

 

 

 

spraxyt
Resting Legend
Posts: 10,063
Thanks: 674
Fixes: 75
Registered: ‎06-04-2007

Re: IMAP 14300

Have you tried capturing samples of the blocked packets to see what they contain?

David
bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: IMAP 14300

Your firewall logs are showing TCP responses originating from one of the actual mail collection servers (in this case mailc11).

You're talking to the virtual IP for the IMAP servers and getting a reply directly from one of the machines behind the load balancer. Due to the IP mismatch, the traffic is seen as bad.

A traffic capture on my machine shows reply traffic coming from the virtual interface rather than the actual mail server. As mentioned though, that might just be because the port 14300 stuff is getting dropped before it reaches me.

To be honest, I'm not sure if it's expected behaviour or not Undecided

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

Anonymous
Not applicable

Re: IMAP 14300

This has happened for years, and I had many discussions with Kelly, Chris, and ejs about how to eliminate it.

It was assumed to be a problem with the Plusnet load-balancers - which of course Plusnet never resolved.

 

It happens when using IMAP with Plusnet email servers.

I have other IMAP connections to other email providers and it doesn't happen with those.

I use various versions of Thunderbird.

 

On my pfSense router, I have set up a special rule to prevent this garbage filling up my firewall logs, by specifically allowing unexpected packets from the ten Plusnet email servers "mailc01.plus.net" to "mailc10.plus.net" to port <14301> on my WAN port.

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: IMAP 14300

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.

I have other IMAP connections to other email providers and it doesn't happen with those.

What do you know about their server architecture? Can you be confident their mail servers are behind load balancers too?

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

Simon
Grafter
Posts: 64
Thanks: 3
Registered: ‎01-08-2007

Re: IMAP 14300

Thanks Nibiru... not just me then!

Unfortunately SmoothWall (Express) needs IPs rather than names to allow in.. (unless I write something to get addresses from mailcXX.plus.net and put into ipatables, so no then!)

.. do the IPs of mailcXX.plus.net change much? If not I can put the IPs in, although the destination ports don't seem to be 14301 but vary (see log extract above).

Anonymous
Not applicable

Re: IMAP 14300


@bobpullen wrote:

Thanks @Anonymous, saves me a job trying to replicate the 'issue'.

I would help out more frequently if I didn't have to constantly battle with this poxy new forum losing my replies, and taking forever to do anything.

 

 


@bobpullen wrote:
@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.

That is interesting on several levels !

  • My firewall exception is still in place, so I don't know whether port <14301> still does this (without the old load balancers).
  • The OP's firewall log has the similar problem but from port <14300>.
  • My firewall log is NOT showing currently the same symptoms on port <14300>, but I will look more often now.
  • I just checked my firewall rule, and definitely only allows port <14301> and not blanket allow all unsolicited packets from Plusnet mail servers.
  • My firewall rule covers email servers "mailc01.plus.net" to "mailc20.plus.net", and not what I said before.
  • I can't seem to find the previous reports of this, as discussed on the old forum.

 

 


@bobpullen wrote:
@Anonymous wrote:

I have other IMAP connections to other email providers and it doesn't happen with those.

What do you know about their server architecture? Can you be confident their mail servers are behind load balancers too?

I'm not sure what you are asking ?

I'm merely stating that I simultaneously use other IMAP email providers and multiple mailboxes within a Thunderbird session, and that my pfSense doesn't show similar spurious unsolicited packets from the non-Plusnet IMAP services. I have no need to know what anyone else's server connectivity is.

Anonymous
Not applicable

Re: IMAP 14300

@Simon, I'm not aware that the email server addresses change.

 

If it helps, here is the list of IP addresses - as taken from my pfSense system log -

 

email-server-addresses.jpg

bobpullen
Community Gaffer
Community Gaffer
Posts: 16,869
Thanks: 4,950
Fixes: 315
Registered: ‎04-04-2007

Re: IMAP 14300

The IP's haven't changed for years so can probably be relied on.

Nibiru wrote:

The OP's firewall log has the similar problem but from port <14300>.My firewall log is NOT showing currently the same symptoms on port <14300>, but I will look more often now.I just checked my firewall rule, and definitely only allows port <14301> and not blanket allow all unsolicited packets from Plusnet mail servers.

I suspect you're a Force9 customer? 14300 is the rport for Plusnet, whilst 14301 is the rport for Force9 (FreeOnline is 14302 I think).

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

Anonymous
Not applicable

Re: IMAP 14300

Yes I am on Force9, so that explains why my port number would be different.

 

Just as an experiment, I temporarily disabled my pfSense firewall rule to see whether I still have a problem with port <14301>, and immediately my firewall log was filled with dozens of entries like this -

email-firewall-14301.jpg

 

So this fault definitely still exists !  Sad

 

Anonymous
Not applicable

Re: IMAP 14300

@bobpullen, are you going to get this fixed ?,

as there is clearly a reproducible configuration problem with your IMAP servers which can be readily tested, and therefore can be confirmed when you have been able to achieve properly working IMAP connectivity.

Simon
Grafter
Posts: 64
Thanks: 3
Registered: ‎01-08-2007

Re: IMAP 14300

@Anonymous, I don't know if I could put rules in smoothwall for this, in that as NAT is happening, for the incoming packets they won't know which internal IP to go to.

Also (assuming i'm the only one on the internal network) the incoming rules need source IP, original destination port (or allow all) then an internal destination IP and port. The internal port can be left blank (so same as original) but then the (windows) firewall will probably stop it. As the original destination port varies, would have to allow all from the source IP.. I wouldn't be comfortable doing that.

The only feasible thing to do would be to put the IPs into a firewall chain which wasn't logged.. turn a blind eye.

Anyway the source IPs from the last three days are:

84.93.229.67
84.93.229.69
84.93.229.71
84.93.229.73
84.93.229.131
84.93.229.133
84.93.229.135
84.93.229.195
84.93.229.227
84.93.229.229

84.93.238.68
84.93.238.100
84.93.238.132
84.93.238.136
84.93.238.164
84.93.238.168
84.93.238.197
84.93.238.201
84.93.238.228
84.93.238.232

 

 

 

 

 

 

Anonymous
Not applicable

Re: IMAP 14300

 

As you have described, the solution of simply passing the unexpected packets which have arrived at the NAT, onto the original destination isn't ideal, because it relies either on your PC's firewall dumping them, or requiring your email application to accept or ignore them.

 

However the fact that you can restrict this to twenty known source IPs and a single port number, should mean from a security standpoint that you are not compromising your IMAP client to unexpected intruders.

 

I have had my firewall rule in place for years without any side-effects.

I didn't know what else to do as my firewall log was otherwise rendered useless because it was 99% filled with Plusnet email server entries - making looking for real threats nearly impossible.

 

Hopefully this time @bobpullen will actually fix this once and for all