• 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 Bug? Plesk NAT uses internal ip for subdomains instead of public IP

Talistech

Basic Pleskian
Hi fellow Pleskians,

One of my Plesk servers is running with a NAT configuration. Everything seems to be working fine for now but there is only 1 small issue and I'm nut sure if it's a bug or not.
Lets say for example my internal address is 10.10.10.1 and my public address is 99.99.99.99.

All domains have records with 99.99.99.99 even though the server has ip 10.10.10.1, this is because I have set up 99.99.99.99 as public IP under IP Settings. So far so good.
When I create a new domain (for example domain.com), that domain also gets new dns records (mail,www,etc) with the record 99.99.99.99.

The issue is when I create a subdomain for that domain (for example forum.domain.com) that particular record gets created under my main domains DNS with the record 10.10.10.1 so I have to edit that manually to my public ip.

Is that a bug or is a feature or a setting?

Thanks!

Kind regards,
Talistech
 
I don't think that intended behavior. At the same time I can't replicate this behavior on a test server.

How many public IP's do you use you on your server?
 
I don't think that intended behavior. At the same time I can't replicate this behavior on a test server.

How many public IP's do you use you on your server?
Hi Kaspar, thanks for your reply.

1 internal IP (which is SNAT and DNAT'ed via my firewall) and this same internal IP has a public IP set via Settings -> IP Addresses.
Let me provide you some screenshots and another test so I can reproduce it.
 
I don't think that intended behavior. At the same time I can't replicate this behavior on a test server.

How many public IP's do you use you on your server?
Upon trying to reproduce it I have found that my issue is slightly different than I have said earlier.
-> Creating a new subdomain gets created with the correct ip address under the main domains DNS records.

But what is really going wrong is:
-> What is happening on your test server when you click "Reset to default" on your main domains DNS settings? On my server the internal IP is used for subdoains but the public ip for the rest.


Do you have still your test server running? Can you test this?
 
Look at the difference clicking Reset to default and after.
Notice the ip's startign with 178(public) and 10 (internal).
 

Attachments

  • 1721648260345.png
    1721648260345.png
    58.7 KB · Views: 6
  • 1721648323717.png
    1721648323717.png
    55.4 KB · Views: 6
  • 1721648373901.png
    1721648373901.png
    23.1 KB · Views: 6
Got it. Thank you for clarifying this. I was able to reproduce the issue you are discribing.

I have forwarded this issue for further analyses by our engineers with issue ID PPS-16364.
 
Issue has been confirmed by our engineers and will be fixed in a Plesk future update. The issue can be tracked with ID PPPM-14509 on the change log.
 
We have released an update which fixes the issue with subdomain’s A record pointing to the private IP rather than a public one on on Plesk servers behind NAT. If you have automatic updates enabled this update should have been installed already. Plesk Obsidian 18.0.63

Fixed the issue where, on Plesk servers behind NAT, resetting the DNS zone for a subdomain to default resulted in the subdomain’s A record pointing to the private IP address instead of the public one. (PPPM-14509)

Please let us know if you encounter any further issues.
 
Back
Top