Can't connect to Virmach VPS through home internet anymore
My Virmach DALZ008 VPS is up and running fine for last few weeks, however starting yesterday I can no longer access it from my home internet. Anyone tell me what is most likely going on here?
The VPS is online and the Virmach billing control panel, SolusVM control panel, VNC are all working normally.
From home internet it now always times out:
PS C:\Users\New User> tracert 45.42.215.xxx
Tracing route to 45.42.215.xxx over a maximum of 30 hops
1 1 ms 4 ms 7 ms 10.0.0.1
2 11 ms 10 ms 25 ms 96.120.73.17
3 12 ms 11 ms 18 ms 24.124.224.129
4 13 ms 12 ms 13 ms 68.85.63.97
5 15 ms 14 ms 14 ms be-31133-cs03.newark.nj.ibone.comcast.net [96.110.42.41]
6 11 ms 12 ms 11 ms be-1311-cr11.newark.nj.ibone.comcast.net [96.110.35.74]
7 13 ms 13 ms 13 ms be-303-cr12.newyork.ny.ibone.comcast.net [68.86.84.242]
8 13 ms 13 ms 13 ms be-1112-cs01.newyork.ny.ibone.comcast.net [96.110.35.129]
9 12 ms 14 ms 11 ms be-3111-pe11.111eighthave.ny.ibone.comcast.net [96.110.34.18]
10 13 ms 20 ms 12 ms nyk-b6-link.ip.twelve99.net [62.115.52.129]
11 11 ms 19 ms 11 ms internap-ic375807-nyk-b1.ip.twelve99-cust.net [213.248.66.102]
12 13 ms 15 ms 12 ms border1-po1-bbnet1.nyj004.pnap.net [216.52.95.46]
13 13 ms 12 ms 12 ms dedipath-48.border1.nyj004.pnap.net [74.201.164.150]
14 94 ms 31 ms 48 ms 45.92.192.123
15 * * * Request timed out.
But traceroute from my LaunchVPS VPS shows it's fine:
traceroute to 45.42.215.xxx 45.42.215.xxx), 30 hops max, 60 byte packets
1 _gateway (76.8.60.1) 0.183 ms 0.128 ms 0.106 ms
2 gi0-0-0-8.nr11.b002999-2.phl01.atlas.cogentco.com (38.140.17.49) 0.965 ms 1.045 ms 1.082 ms
3 te0-1-0-0.rcr21.phl01.atlas.cogentco.com (154.24.50.85) 0.952 ms 0.959 ms te0-1-0-0.rcr22.phl01.atlas.cogentco.com (154.24.50.89) 2.272 ms
4 be2958.ccr41.dca01.atlas.cogentco.com (154.54.25.241) 4.521 ms be2964.ccr42.dca01.atlas.cogentco.com (154.54.26.121) 4.501 ms 4.481 ms
5 be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 20.696 ms be2113.ccr42.atl01.atlas.cogentco.com (154.54.24.222) 20.717 ms be2112.ccr41.atl01.atlas.cogentco.com (154.54.7.158) 20.697 ms
6 be2690.ccr42.iah01.atlas.cogentco.com (154.54.28.130) 34.054 ms be2687.ccr41.iah01.atlas.cogentco.com (154.54.28.70) 34.357 ms 34.336 ms
7 be2443.ccr32.dfw01.atlas.cogentco.com (154.54.44.230) 39.326 ms be2441.ccr31.dfw01.atlas.cogentco.com (154.54.41.66) 39.528 ms 39.499 ms
8 be2938.rcr21.dfw04.atlas.cogentco.com (66.28.4.18) 40.022 ms 40.162 ms be2939.rcr21.dfw04.atlas.cogentco.com (154.54.6.114) 39.917 ms
9 be3795.nr51.b028597-0.dfw04.atlas.cogentco.com (154.24.61.202) 40.324 ms 40.573 ms 40.335 ms
10 38.140.239.18 (38.140.239.18) 40.678 ms 40.741 ms 40.672 ms
11 border5.ae1-bbnet1.dal006.pnap.net (216.52.191.44) 37.856 ms border5.ae2-bbnet1.dal006.pnap.net (216.52.191.109) 39.797 ms 38.140 ms
12 dedipath-57.border5.dal006.pnap.net (107.150.158.10) 40.879 ms 40.914 ms 40.886 ms
13 185.161.69.135 (185.161.69.135) 39.931 ms 39.971 ms 39.997 ms
14 45.42.215.xxx 45.42.215.xxx) 39.349 ms !X 39.377 ms !X 39.167 ms !X
???
Comments
You have most likely banned yourself with your firewall script or fail2ban.
Search the iptables and ip6tables rules for a match with CSF:
csf -g [IP.add.re.ss]Search for IP address in fail2ban.log:
cat /var/log/fail2ban.log | grep "IP.add.re.ss"etc.
Thanks @kasodk . I've checked IP tables and Fail2ban log previously. I've also tried connecting from three different IP address (all Comcast cable IPs) with no changes. Other things have tried are rebooting computer, rebooting cable modem, flushing DNS cache, trying 3 different computers, and connecting through neighbor's internet.
I also have a purple daddy VPS out in California and it CAN ping the Virmach Dallas VPS too. It seems only local Comcast IPs won't connect.
This issue seems bizarre to me... Don't want to open a ticket because I know Virmach support is crazy busy at the moment and it's a Black Friday/no support VPS- and technically it IS online. Usually when weird problems happen with my VPSs it turns out to be something I've done on my end but have tried very hard to eliminate all the variables.
Was hoping someone could look at the traceroute IP info and say "THIS is what is happening" but guess it's not going to be that easy.
I'm not a networking guru or anything so I could be wrong here but if you can't reach the neighboring IPs as well, then it's safe to say it's not your VPS specifically, but most probably some Comcast ranges or
AS7922is getting blocked/filtered by their upstream for some reason(s)."The imitator dooms himself to hopeless mediocrity." — Ralph Waldo Emerson
Looks like it's VPN time.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
NordVPN is a VPN service with applications for Microsoft Windows, macOS, Linux, Android, iOS, and Android TV. Manual setup is available for wireless routers, NAS devices, and other platforms.
NordVPN is developed by Nord Security, a company that creates cybersecurity software and was initially supported by the Lithuanian startup accelerator and business incubator Tesonet. NordVPN operates under the jurisdiction of Panama, as the country has no mandatory data retention laws and does not participate in the Five Eyes or Fourteen Eyes intelligence sharing alliances. Its offices are located in Lithuania, the United Kingdom, Panama and the Netherlands.
♻ Amitz day is October 21.
♻ Join Nigh sect by adopting my avatar. Let us spread the joys of the end.
Windows traceroute and unix traceroute work a little differently. Windows by default will send ICMP ehco request packets in the trace, unix will use UDP messages. Is it possible ICMP messages somewhere near your target destination are being filtered?
Dataplane.org's current server hosting provider list
@jtk @TheDP Don't really have enough networking knowledge regarding ICMP messages etc. but at this point I also think it's likely something is being filtered or routed incorrectly by someone
@AlwaysSkint I just downloaded Opera web browser because it has free VPN service and WAS able to connect to my Dallas Virmach VPS Virtualmin control panel. Usually very slow and many time out / tunnel errors and reloading, but it did connect. I'm on the east coast USA and for some reason choosing a European based VPN IP worked more reliably than choosing a local US VPN IP address
At this point unless I get some different info am going to assume this issue has nothing to do with my VPS configuration or any thing under my control. If it doesn't start working again in a week or two will try reinstalling the OS but don't see how that will solve anything. Currently don't have any live websites on it which is a good thing because at least part of the country wouldn't be able to access them anyway
Not going to tag him but - Mr. Vir Mach if you read this please let me know your thoughts.
Can you reach/trace the other IPs within the same subnet of your VPS’s IP?
Just pick some random IPs before or after yours.
If you can, then it’s your node.
But if you can’t, it’s most likely not your node, but something for VirMach and their upstream (DediPath?) to look into.
"The imitator dooms himself to hopeless mediocrity." — Ralph Waldo Emerson
I just tried the 10 IP address directly preceding my IP and the 10 directly after it. My method was to type the full IP into Chrome browser address bar and hit enter. If this isn't a good way to check please let me know
All 20 timed out, no connection
Some odd routing there; from your VPS it bounces around cogent before getting down to dedipath's DAL border, but from your home connection it goes into their NYJ border and then gets lost. Might be something up with their routing?
Reminder: VirMach has Looking Glass in Dallas (and almost all locations) now: https://billing.virmach.com/index.php?rp=/knowledgebase/11/Test-IP-and-Looking-Glass-Locations.html&language=english
Probably worth to test if you can access lg and lg routes
Haven't bought a single service in VirMach Great Ryzen 2022 - 2023 Flash Sale.
Most likely scenario, IMHumbleO. When I was daft enough to have a server in LA (different provider), there were some funky routes at times. A routing table gone fubar.
Virmach did mention an issue with Dallas at some point, hence me migrating one VPS to SEA - along with another reason.
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
edit: removed wrong info
Many servers are not used for web hosting, so use traceroute or ping instead.
Blimey that was rapid, from the UK:
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Didn't think of that. Just repeated the test of the closest 20 IP address using ping, all 100% loss/no connections
Then read this again:
https://lowendspirit.com/discussion/comment/99503#Comment_99503
Done a test from OVH (East Coast):
Completed fine, once the OVH network got its act together. It does appear to me that it's a hiccup at ASN 35913
Can you shed some light, @Virmach? (If not sleeping!)
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
Is this Comcast? They intercept ports 80 and 443 of my Buffalo VPS but I can still ssh. Apparently that server's IP range is in some kind of scam of phishing blacklist.
The 45.42.215.* subnet is blacklisted by @jarland.
Use the PDiddy vps to ssh into Virmach Dallas. Why lost sleep over this trivial matter?
Mods: Title may need editing. If Provider is not at fault here, why does title mention their name?
OP begins with Virmach, then ends up with Jarland. Mentions PDiddy for good measure. Only 53 more names to go
blog archives
This is stupid.
It is a Virmach VPS and the subnet is blacklisted at mxrbl.com (run by mxroute.com).
Both providers are relevant to OP's problem.
Stupid is you.
OP pays Virmach for a service, can raise a ticket 🎟️ optionally for a price, since BF deal and all… but OP looks for free consultation here instead. and and here we are, making asinine comments .
blog archives
No, you are making stupid accusations and asinine comments.
The rest of us have tried to help.
The PMS is high on this one. Taking a look back at the conversation:
-OP using Windows from home machine? Local machine firewall blocking for some reason?
- What is the VPS used for? Was any process / application being run that set off a few alarms?
- LG for Virmach Dallas is a 172 block, OP VPS appears to be a 45 block/ not sure how LG will be helpful in this case
- Biggest issue of all- why is OP NOT raising a ticket with @Virmach? Something preventing them from doing so? If so, what is? Inertia is a fairly innocent answer, but that may be wishful thinking.
- If the VPS subnet is blacklisted by MXRoute, what is the relevance/ significance to OP? Are they running a mail server? Does Crapcast follow the MXRoute Blacklists (do they use that term anymore - Crapcast? Used to be popular when I was their customer)
- Oh forgot this one- since I was labelled as making "stupid" accusations. I used to be a MaxKVM customer, so by extension I cannot be stupid. Look back at the messages. OP has left out enough details to raise flags. Prudent behaviour if considered asinine, is okay- mindlessly assuming provided information by OP is accurate, is not.
blog archives
That !X doesn't seem fine to me.
@Janevski By "fine" I mean it's currently working for me as in sending daily backups of my website to the Dallas DAZ008 machine. And also I can ping Dallas from it and I can't from home. And traceroute does not time out. If there are issues with the connection between the two VPS doesn't seem to be causing problems for me at least in this instance.
Don't know what the !X means in the trace, that's why I came here for help free consultation
At this point am going to guess AlwaysSkint's suggestion of FUBARed routing table is most likely with Comcast blocking access as runner up. Time will tell.
edit: typo
We've had some really strange issues with our internet (Comcast) recently at the office here. At the same time when I was looking into what was going on with QN Los Angeles and Dedipath Los Angeles, I noticed the same weird thing going on for Dallas. We had a network engineer at QN confirm various things for us and it looked like it wasn't any issue with the networking equipment and then it started being fine again without any intervention.
But there definitely was something up with it at least to our office and a few other test servers and at the same time. And it looked similar to what OP posted, plus it was in a similar timeframe.
Speaking of which I'm not saying this is your issue but if you did that, and this was going to be my second guess, the system might block you. I was going to ask you if you had done anything like that but now we know you definitely did it afterward if you didn't do it before so there's a likelihood that you're blocked until it drops it.
Okay good thing you pointed that out, initially I scrolled past it and didn't notice. This means potential firewall issue. More specifically, it's icmp-host-prohibited.
Private message me your IP, your service's IP, and your other one as well. I"ll check to make sure it's not on our end.
One final issue it could be and honestly I'm going to bet on this one based on everything else I just said, is that maybe SolusVM glitched out when assigning the IP address to you or at some point in time and if any rules were reloaded, especially as a part of me taking a look at Dallas and LAX as I mentioned, it could mean that your service would effectively get blocked from using that IP address as part of SolusVM's protection. And maybe that IP address is pointing towards another VPS now and you just got banned for too many failed login attempts and that way the other VM could also easily have that icmp-host-prohibited rule as that's not uncommon.
(edit) But nevermind then it wouldn't make sense that you couldn't ping the others. It has to be a combo.
Reading Virmach’s wall of text above, it is evident that wht should have been a ticket 🎟️ from OP to Virmach, will now be addressed via PM, so still a 1:1 that the “helpers “ and “advisers” will not be privy to, unless shared by OP or Virmach with OP permission.
Paying customer resolving 1:1 with services provider who is recipient of payment. Which was my point.
Now who should feel stupid?
Have a nice day
blog archives
Can probably whitelist as requested if need be.
Do everything as though everyone you’ll ever know is watching.
Don't, virmach has stained they underpants enough to be pre-banned by all email server operators. Thank you.
Okay so I figured I'd give you an update here in case anyone is interested, might as well. It definitely seems to be a routing issue and also seems to be some weird coincidence. I've contacted everyone to correct it on their end but somehow the /24 IPv4 we leased for DALZ008 around May 2022 or so got announced with AS35913 (INAP) as expected, BUT
I was essentially writing out a long drawn out ticket to get it relayed to INAP to take a look since everything looked OK on our end and by the end of it I realized it didn't make sense that it'd happen around the same time we had the reported issues in LAX.
So I looked up the IRR on HE and it looks like the block is still announced from 2021 and it just happens to be with AS29802 which is Hivelocity and it's marked as their LAX datacenter. So I don't know what finally "activated" it but I'm having that looked at now. Basically it looks like NYC Metro is having problems connecting specifically to this one /24 block, and the nameservers (8.8.8.8, 8.8.4.4) have 30ms ping because it's now effectively updated as being in Los Angeles because BGP.
AlwaysInterested
In stasis until the shitposting stops/abates.
Than=compare;then=sequence:brought=bring;bought=buy:staffs=pile of sticks:informations/infos=no plural.
It wisnae me! A big boy done it and ran away. || NVMe2G for life! until death (the end is nigh).
You clearly should.
Because it is stupid to attack people because they ask for help on a forum.
Especially when you are LES staff (Content Writer).
Could we kindly tone it down on the “stupid” remarks going forward? If everyone calls everyone stupid, MaxKVM will have nothing to say upon their return.
Michael from DragonWebHost & OnePoundEmail
You can cut from my “staff” salary everytime I say Stupid.
Apparently I get paid a lot writing
Enough of this crap. Buffoons less than two weeks here make allegations, of attacking.
What was and should have been a ticket with the concerned provider has taken a dump.
Outta here.
blog archives
I disagree.
I think people should do their own troubleshooting first. It is a good idea to search the internet for troubleshooting information. It is also good to learn by asking in internet forums. Perhaps you missed something obvious or lack one tidbit of knowledge that experienced people take for granted.
Opening a ticket is the last resort. You open a ticket after you have read the manual and done your own homework, research, and troubleshooting.
In my opinion, people open tickets and call the manufacturer for help far too often. They don't bother to analyze the problem for themselves any longer. In my opinion, this behavior change has resulted in the "dumbing down" of customer support. By the time I am ready to open a ticket or call for help, I am often at the point where I know more about the product and the problem than the support person. It can be frustrating when the entire customer support apparatus does not know enough about their products to provide real support beyond scripts like "Is it plugged in?" "Let's reboot it and try again." "Delete all of your settings and customization and work, reinstall the product, reconfigure everything and call us back in a week. Did the problem go away?"
Asking your friends for some helpful advice on LowEndSpirit is not "free consulting" but an effort to try and learn to do better troubleshooting rather than resorting to tickets.
Some friends you are.
I haven't really read what everyone's been posting about what should and shouldn't have been a ticket in our system and I'll say in this instance it was definitely helpful that it was not a ticket as it turned out to be an abnormal event where without much information and discussion, it would have been very easy for it to have a negative outcome with how our tickets are going right now.
OP definitely appears to have first done his due diligence to a very high level before coming here for help so it's not just a case of a customer immediately going to a message board to blast a company to try to get priority support.
If he had first presented all this information in a ticket, there's a high chance we would reach a conclusion there as well but it would be hindered by the volume of "other" tickets and obviously our biases that go into that when the last hundreds of reports we've primarily looked at have been vague and already resolved or not on our end.
Anyway, my vote goes for thinking this would be a good example of what should be posted to a "help" section of a hosting-related message board, whether or not the host is part of said message board as it's equally likely someone here would have eventually noticed the double entries on RADB versus a technical support agent at any host company noticing first.
This should never occur, sack any and all staff that treat any customer correspondence with any form of bias due to other tickets - I get some are even bording on ridiculous at times, having had a fair few myself over the years but if your staff have that mindset you may aswell give up now!
Having said that, it's absolutely an appropriate discussion to have here, it's very silly to suggest otherwise! It's also beneficial to others!
I'm just being realistic here. In any profession, even if you are aware of potential biases, it's definitely easier for you to accidentally misdiagnose something. I agree with you that anyone should strive to avoid that but there's no way to completely 100% get rid of that when humans are involved.
It is unfortunately how a brain functions. If you are presented with 999 situations that fall in line one way and then 1 situation that's extra-ordinary, there's a likelihood of it being mislabeled.
Luckily we're only speaking of servers here and not human lives. There have been plenty of cases that represent this issue in aviation and medical care, where lives are directly at risk.
You can and you should, it's OK to think it may be X/Y/Z and check that first but every ticket should be treated as a new problem until resolved! I'm not trying to be argumentative here - I'm just of the opinion it leads to less work in the long run!
Any staff with that mindset will ruin your business reputation for you though
Greetings,
if the provider in question is okay with and has tacit consent for using LES as extended helpdesk, then I stand corrected and I concede. My past comments on the matter may be treated as void.
blog archives
This subnet is reachable from Comcast business line in Washington DC area.
Source IP: 50.253.56.21
We accept Karma donations for the last flan. 🍮 affbrr
I'm reminded of the mom who goes to watch her seventh grader march in the school parade. Sitting with her friends she exclaims: "Look. My little boy is the only one in step." Funny how ALL of the network disasters strike Virmach and nobody else in the industry. We have 40+ servers with different providers just to test functionality for the Incredible PBX project. Guess which one (and only one) regularly fails to connect?
Very happy to report that today the weird routing problem was having accessing my VPS on DALZ008 has been apparently been resolved. and it's accessible from home again. Thank you to everyone who offered advice. Below are the 10/14/22 results from my Comcast residential IP address:
** Tracing route to 45.42.215.xxx over a maximum of 30 hops**
Yep, confirmed on my end some time yesterday or the day before and also fixed the accompanied panel issue. I was actually looking for your ticket and couldn't find it in the sea of tickets but just remembered there was a thread here and came in to check, so I'm glad it's working for you again.