• Feedback needed for mail auto-discovery and management improvement: If you regularly handle mail-related tasks in Plesk for yourself or your clients, please take a moment to participate in our survey and share your experience.
  • If you are still using CentOS 7.9, it's time to convert to Alma 8 with the free centos2alma tool by Plesk or Plesk Migrator. Please let us know your experiences or concerns in this thread:
    CentOS2Alma discussion
  • Please be aware: Kaspersky Anti-Virus has been deprecated and is no longer available for installation on the current Plesk release (18.0.63).
    Starting from Plesk Obsidian 18.0.64, the extension will be automatically removed from the servers it is installed on. For details and recommended actions, see the Feature and Deprecation Plan and the deprecation FAQ.

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