• We value your experience with Plesk during 2024
    Plesk strives to perform even better in 2025. To help us improve further, please answer a few questions about your experience with Plesk Obsidian 2024.
    Please take this short survey:

    https://pt-research.typeform.com/to/AmZvSXkx
  • The Horde webmail has been deprecated. Its complete removal is scheduled for April 2025. For details and recommended actions, see the Feature and Deprecation Plan.
  • We’re working on enhancing the Monitoring feature in Plesk, and we could really use your expertise! If you’re open to sharing your experiences with server and website monitoring or providing feedback, we’d love to have a one-hour online meeting with you.

Resolved Webmail Site unreachable

jonny_alex

Basic Pleskian
IP-Adresse
82.220.34.93
System:
CentOS Linux 7.8.2003 (Core)
Product
Plesk Obsidian:

I got a seriously confusing issue with one particular domain.
If i open webmail.design***.ch the Site isn't charging up and ends up in an error.

All other pages on the server are responding and accessible..
Also on Outlook Mail can't add my acccount to read my mails..

Tried to reinstall the Site with no result and also checked dns records

Anyone familiar with this problem? For me it's important to make those Mails work..
 
The page just doesn’t load it ends up stopping to load because it says server timeout or not reachable.. If zou want to try yourself: webmail.designjab.ch
 
The problem is that data packets only go through to your domain name, but not through to subdomains. The name resolution of your subdomains work correctly, but the packets are not routed correctly to your server once they are in the internal network of the data center where your host is located. I don't think it is a configuration issue of the server, but rather an issue in the data center. I suggest to contact your hosting provider over this.

Do-it-yourself test:
Try tracert for designjab.ch (works and reaches your server) and any other subdomain like www.<yourdomain> or webmail.<yourdomain> (stops in some router in the data center before your host).
 
1 * * *
2 82.220.32.152 (82.220.32.152) 5.279 ms 5.521 ms 5.746 ms
3 ixnzrh-bbm02-40g-0-0-3.solnet.ch (82.220.13.17) 64.577 ms 64.648 ms 64.73 7 ms
4 eq2zrh-bbm02-100g-0-0-2.solnet.ch (82.220.13.50) 4.476 ms 4.503 ms 4.573 ms
5 colozh-bbm01-100g-0-0-1.solnet.ch (82.220.13.39) 4.342 ms 4.333 ms 4.396 ms
6 vtlbrn-bbm02-40g-0-0-3.solnet.ch (82.220.13.48) 5.114 ms 5.328 ms 5.362 m s
7 vtlbrn-bbm01-v-2006.solnet.ch (82.220.12.196) 8.715 ms 8.768 ms 8.889 ms
8 d11sol-bbm01-40g-0-1-1.solnet.ch (82.220.13.4) 7.286 ms 7.036 ms 7.001 ms
9 d11sol-bbm04-x-0-0-1.solnet.ch (82.220.12.143) 32.517 ms 32.617 ms 28.438 ms
10 212.101.0.81 (212.101.0.81) 5.295 ms 5.164 ms 5.191 ms
11 ***

What does this mean?
 
What you are seeing is the route that a data packet takes through the Internet to reach your server. In step 11 you notice the ***, it means that no packets are going through. From hop 10 to hop 11 there is an issue for the packets of all your subdomain addresses. They seem to resolve correctly in your nameserver though. When you compare the same traceroute with one that you do for your domain name (without subdomain prefix), it will complete correctly. So there is an issue with the routing in your data center or with a firewall before your server that is configured incorrectly.
 
But that doesn't really make sense since all other domain on the same server can connect or do i miss something?

ERR_CONNECTION_RESET is what i receive in Chrome..
I'm kinda confused actually because i also get pushed back from my Domain registrar who tells me to aks my server host (me)..

What specifics of my data center or firewall can i check to solvethis?
 
But that doesn't really make sense since all other domain on the same server can connect or do i miss something?

ERR_CONNECTION_RESET is what i receive in Chrome..
I'm kinda confused actually because i also get pushed back from my Domain registrar who tells me to aks my server host (me)..

What specifics of my data center or firewall can i check to solvethis?

This isn't an issue that is related to your domain registrar so they were right to push back. Your subdomain resolves to your Plesk server so the packets are being dropped or rejected somewhere when trying to reach it.

Try reaching out to your server provider for assistance as they might be able to spot the problem for you!
 
I just found out my server is using the wrong ip even i modified it on my dns records


[root@hosting ~]# traceroute webmail.designjab.ch
traceroute to webmail.designjab.ch (82.220.43.93), 30 hops max, 60 byte packets - !!Supposed to be 82.220.34.93 not 43!!
1 gateway (82.220.34.1) 2.192 ms 2.156 ms 2.162 ms
2 82.220.32.152 (82.220.32.152) 5.183 ms 5.492 ms 5.614 ms
3 ixnzrh-bbm02-40g-0-0-3.solnet.ch (82.220.13.17) 4.305 ms 4.365 ms 4.399 ms
4 eq2zrh-bbm02-100g-0-0-2.solnet.ch (82.220.13.50) 4.373 ms 4.483 ms 4.599 ms
5 colozh-bbm01-100g-0-0-1.solnet.ch (82.220.13.39) 61.923 ms 61.920 ms 62.056 ms
6 vtlbrn-bbm02-40g-0-0-3.solnet.ch (82.220.13.48) 5.163 ms 5.416 ms 5.416 ms
7 vtlbrn-bbm01-v-2006.solnet.ch (82.220.12.196) 6.048 ms 6.155 ms 6.250 ms
8 d11sol-bbm01-40g-0-1-1.solnet.ch (82.220.13.4) 7.296 ms 7.465 ms 7.661 ms
9 d11sol-bbm04-x-0-0-1.solnet.ch (82.220.12.143) 9.282 ms 9.455 ms 9.637 ms
10 212.101.0.81 (212.101.0.81) 5.270 ms 5.288 ms 5.305 ms
11 * * *
12 * * *
13 * * *
14 * * *
15 * * *
16 * * *
17 * * *
18 * * *
19 * * *
20 * * *
21 * * *
22 * * *
23 * * *
24 * * *
25 * * *
26 * * *
27 * * *
28 * * *
29 * * *
30 * * *


How can i resolve this issue?

i already did check the dns records, restarted my server and looked up at mxtoolbox (there it's correctly validated)
 
Do-it-yourself test:
Try tracert for designjab.ch (works and reaches your server) and any other subdomain like www.<yourdomain> or webmail.<yourdomain> (stops in some router in the data center before your host).
That makes no sense. traceroute does not actually use domain names, it just fetches the IP and then sends out ICMP packets with a certain lifetime.
It should not make a difference through which domain name you got that IP if it actually is the same IP. (And for me, it stops at 15 82.220.32.61 36,252ms 25,359ms 25,395ms. ping gets through, however.)

If it does make a difference, that's a sign some kind of firewall/IDS getting the idea it has to "protect" something. You'll notice in that case if you try the traceroute that worked earlier again, it also fails.

But that's not the case here. When did you make the change, @jonny_alex? Sometimes it takes some time for the DNS changes to propagate. Though even when I use nslookup and tell it to use the "server ns1.hosttech.ch", it answers 82.220.34.93.
Did you change plesk's dns server settings but your domain is actually using hosttech's, without delegation? Then everyone outside will get the wrong address until you also change it on their servers.
 
.. and also checked dns records ...
Tonight I must say that I am a bit annoyed, because now obviously it turns out that the dns records had NOT been checked correctly. A waste of time handling this case. :( Unfortunately it is often similar in forum posts. Users state they are sure that something is like A, and when you believe them, it turns out you should not have, because reality is not A but B. I'll try to learn from this case and start checking and confirming all the basic information first before digging into an issue deeper.

That makes no sense. traceroute does not actually use domain names, it just fetches the IP and then sends out ICMP packets with a certain lifetime.
It should not make a difference through which domain name you got that IP if it actually is the same IP. (And for me, it stops at 15 82.220.32.61 36,252ms 25,359ms 25,395ms. ping gets through, however.)
And for some reason I don't like this post either, because you could have simply compared the two traces and would have found, just as @pleskpanel and me, that the domain passes all hops to the server while any subdomain does not, yet both resolve to the same IP. So obviously some system makes a difference to the data regardless of the same IP address. :(

O.k., I realize I am unhappy with this case, but luckily this is free user-to-user support, so we all have a choice to work on it or to not work on it. :)
 
And for some reason I don't like this post either, because you could have simply compared the two traces and would have found, just as @pleskpanel and me, that the domain passes all hops to the server while any subdomain does not, yet both resolve to the same IP. So obviously some system makes a difference to the data regardless of the same IP address. :(
I actually did, and they all stopped at the same point.
 
First of all @Peter Debik i'm truly sorry that i misread it because there was one number switched up in my A Record.. But still this was a change made after i discovered the issue so it didn't change the result, meaning that this issue was there even before this change.

I'm sorry that you feel like wasted time but i just tried to change the result with adding the *.domain.ch Record after i received this error..

But: The problem is solved since i tried this morning and it resolves correctly with traceroute too..

I just want to say thank you and big appreciation for all of your assistance <3 the reason might have been the missing *.domain.ch A record
 
Back
Top