We don't compromise on value or service - HA! (SSH inbound issue)

[#1]

Sorry to hear the "fix" was short-lived.

Hop 8 in your trace shows each of the 3 probes followed different routes at that hop, this first one not responding, the second lacking rDNS and the third giving psb-ir01. It's possible that hop 7 for those probes was different even though the actual hop 7 tests all hit the same router.

Did your comment imply UDP probes were used?

For raising a ticket I suggest logging into Member Centre and going to https://portal.plus.net/wizard/. Only a limited selection of subjects is available, take your pick between DNS and IP addresses in the RH column.

[#2]

Whilst I can't offer you any technical assistance, after reading this entire thread I feel compelled to comment.

Your attitude kind of stinks. You have presented this request for assistance quite impertiently. For example, you know you could do x, y or Z but why should you if it was working before but not now? Well, have PN ever provided or claimed that they would provide you with support on such matters? If not, could it be that you have become complacent with something working and just expect and assume help is at hand when it stops?

You then asked a series of questions and when someone explained re the priority if the fix you responded by saying you were unconcerned. Charming.

Then, upon thinking the issue is fixed by something you SHOULD have done yourself to begin with, you have the temerity to say that the CSA should have advised you to do it. This is completely contrary to the tone of everything you'd said up to that point. Because let's be honest, you're an advanced user who would have been appalled if they'd even had the gall to suggest you'd not performed the first step of troubleshooting yourself.

And ironically even when you thought the issue was fixed you suggested you were still to take your custom elsewhere. Now the issue has come back and really you've only the good will of other advanced users to suggest further assistance. Maybe that's karma but good luck getting it fixed with your new cheaper and apparently much more helpful soon-to-be provider eh!

Gosh, the cheek.

[#3]

@spraxyt - again, thank you. Yes, UDP, as well as TCP (both with modified headers) and ICMP of varying types. I believe the more modern terminology is "fire walking" (though I've by no means been aggressive).

@stewakeman - thank you for your clearly considered response.

You'll note, since you've read the whole thread, that I clearly stated that I'd be perfectly happy if PN were to bill me for this type of support.

Let me give you an analogy...

Lets say that I purchase a car (outright, no loan or ongoing contract other than warranty) and suddenly one day, the engine management light comes on, though there's no loss of performance in any way. Lets also say that I have enough autoelectrical/mechanical skill/knowledge to read the fault code, and it comes back as something rather ambiguous.

Now, I consider the EML light a problem that I want resolved. So I take the car to a garage.

In such a scenario, I fully expect that the garage will reply something along the lines of "sure, we'll take a look, but if it's something not covered by the warranty, we'll have to bill you, regardless of if you decide you want us to actually fix it - you'll need to pay the hourly rate for us to investigate if it's not covered by warranty." That would be perfectly reasonable of them.

I also expect that if the garage should reasonably fix this issue under warranty, they do so at their own cost.

One of the customers says something along the lines of "cycle the ignition a couple of times, I've heard it clears the fault code" - so I attempt it, and the EML comes back on regardless the next day. So I go back to the garage, armed with more information.

While I'm talking to the mechanics/receptionist, one of them says "Oh, the ramp is broken at the moment" and I reply to tell them I'm not concerned, I want them to investigate my car, how they achieve that is up to them.

Now, lets consider that some other customers are at the garage at the same time, some of whom choose to attempt to be helpful - and I express my thanks to those. Other customers, tell me I have a "cheek" for expecting a service that I'm prepared to pay for if required. Some of those customers telling me that I have no right to request such service of the garage, also (wrongly) tell me that I'd be upset if the garage told me to cycle the ignition a couple of times to try to clear the code.

Throughout this discussion with the garage, I repeatedly hint that I may go elsewhere for this service, and I may be able to get it cheaper. They may not care, but I hint anyway. Only, in the case of a warranty issue with a garage, I also know that if another garage fixes it, and charges me, I'm well within my rights (under the warranty) to pass that bill to the garage that sold me the car. That part of the analogy doesn't work with ISPs.

PN advertise themselves with statements such as "we don't compromise on value or service" (hence the title of this thread), and "broadband that loves you back" - as well as other claims about good customer service. I've worked in customer services, I've been a CSA for a tech company. I wouldn't ever dream of telling a customer "we can't advise you anything on that subject, and I can't raise a ticket for someone to investigate" - and my employers never tried to "brag" about their products or customer services.

[#4]

My router firewall has logged an average of about 40 incoming probes to TCP port 22 every day, and I've been on the "new network" for 4 months.

I still strongly suspect the issue is with the 2704n router, and a more "normal" router, that will forward ports to a specific IP address, wouldn't have this problem. I think about the only thing Plusnet could do (quickly) about it is to give or sell you a Hub One, although if they asked you to pay the full price for a Hub One, you could probably buy a more suitable router for less elsewhere.

Also, here's an idea from borrowed from another thread: try and connect to TCP port 7547. This port should be open, the router itself is listening on it, it's used for CWMP (TR-069). If you can connect to that, then incoming connections are reaching your router. You might need to temporarily turn off DMZ, otherwise the router might be trying to forward it to a non-existent device or some other device besides your Pi.

[#5]

@ejs - again, thanks.

40 per day is quite light. The Pi is configured to only allow the same IP to attempt 3 times per minute, then packets are dropped by the iptables, rather than accepted. From there, a script parses auth.log and creates SQL statements. The database is then used to allow/deny access to other services (a kind of blacklist). Even with the rate limiting, I've been observing around 70 probes (not necessarily 70 unique IPs) a day.

Assuming the 2704n is the fault, this doesn't explain why it was working and has suddenly ceased. It also doesn't explain the "no route to host" I've been occasionally seeing.

That said, I've just attempted a few more remote connection attempts (with DMZ disabled):

• Telnet port: immediate connection refused. Expected anyway. People that leave this port exposed need shooting!
• CWMP on 7547: immediate connection accepted! Short delay, then connection dropped (presumably because I didn't initiate a session).
• SSH port (using telnet): pause, followed by connection timeout. No packet counters changed on the Pi firewall.

I then decided to nmap my PN IP from a remote location, looking at ports 22, 23, 80 and 7547. Filtered, closed, filtered and open (in that order).

Next, I dropped the port forwarding rule, and re-ran the nmap scan - same results (rather unsurprisingly).

So I added the port forwarding rule back again, and now I'm told the SSH port is open! SSH confirms this.

Intriguing to say the least, and certainly appears to back up your theory @ejs (and the opinion of many others on the forum, that the PN supplied router does the job, just about, but is otherwise garbage).

Push comes to shove, I could probably replace the PN router with a TP-Link, though I don't know (yet) if that would leave me with the required number of eth ports (overall). I'd also have to run some cable.

I'll continue to monitor, and report back with anything of importance.

Thanks again.

[#6]

@redtela, any further observations on this one?

If you're still using the 2704n and still subject to the problem then I'd like to try something out.