web GUI from IPv6 client

From our user feedback we do not at all get the impression that there is an urgent need for an IPv6 capable web server in PRTG. The general usage of IPv6 throughout our customer base is still very very low. Although I agree that it would be great to have IPv6 in PRTG's web server we have to direct our development resources as to achieve the most "bang for the buck" for the product and for the majority of our customers. And in this case we have decided to postpone IPv6 for some time, there is no ETA that I can give you right now.

See my blog article "How We Rate Your Feature Requests": https://www.paessler.com/blog/2012/07/03/other/how-we-rate-your-feature-requests-company-culture-2

Now we're in 2015. Still no plans to make the webserver ipv6 capable? Multiple ISP's are pushing their customers in my country to ipv6 (dual stack). About 30 to 40% of the (first) DNS query's are AAAA instead of A. Feels like I'm betting on the wrong horse...

As you can see, there have been no further requests for a IPv6 capable PRTG web server for over 2 years. That meant, we had to put this on a very low priority, as other features (requests) have been much more popular. We still have it one the list though, and will keep an eye on this thread!

We and some clients would like it to start use ipv6 on the webserver.... is there any ETA?

If supplies are waiting for the customer to start use ipv6 and the customer is waiting for the supplier to support it this is never going to happen.

Google didn't start with ipv6 because people where asking about this.

We have a problem with the web GUI on android since we have IPv6 in our network I can't connect to the web server because it is trying to connect to the IPv6 address.

How about the official PRTG mobile app..... we can't connect anymore with the app on andriod because our phones are using IPv6.... some maybe it would be good to support IPv6 on the webserver, this is the future Internet.

Well, I was just evaluating PRTG to use it in our environment. However, lack of IPv6 is a show stopper for me. Back to Nagios.

Just to explain why we need IPv6: many of our servers are behind NAT. Sometimes multiply NAT. Accessing them through global IPv6 address is much simpler and faster.

I would vote for PRTG webserver to begin supporting IPv6 at least on the road map with a goal of the next 12 to 18 months supporting IPv6 as a web host. Any end point on mobile carrier and even residential cable services in the US are going to be very soon IPv6 only at least for new service customers. So if I have a remote probe out there, I need to be able to connect an IPv6 PRTG host. Our PRTG hosts are properly configured for IPv6 on our network already. We are looking to begin monitoring IPv6 devices, it appears that most common sensors already support IPv6 which is great news!

Not having IPv6 web host shouldn't be a game stopper by any means for using the PRTG platform.

Come on guys... it's November 2015. Every web server supports IPv6, time to make this happen.

We've been running IPv6 internally for a while. After finally receiving an IPv6 allocation from our providers we've decided to switch it on for external access to our services.

Imagine our surprise when we found a piece of software, specifically designed for network stuff, doesn't support what is one of the most important things happening in our industry. If we and industry pro's can't do this, how can we expect the rest of the world to?

+1

Hi, I want to Use the webserver via IPV6. Why this work? Every Year we pay for maintenance... 2011 Paessler says "Wir arbeiten derzeit an der nächsten großen Version von PRTG und diese wird natürlich auch IPv6 unterstützen." Whats going on? I need the native IPV& not an workaround after many years IPV4.

Matthias

Matthias, I'm afraid there may be a slight mix-up here. The IPv6-Support announced in 2011 was for part of the available sensors, not the webserver or Probe Connections though.
To explain a bit why this is not yet available, not even 1% (by far) of all sensors in PRTG are using IPv6. So there is very very very little usage of IPv6 in relation to our application, while in turn the development efforts would be so huge to implement IPv6 support for the webserver and Probe Connections. Due to this very skewed relation, we rather invest the development time into features and improvements where much more installations benefit from.
We do of course listen to our users, so should this relation change significantly, we will look into the decision again.

I would vote for PRTG webserver to begin supporting IPv6.

Hello,

if you "all" just need to Access the webServer part of your PRTG Infrastructure via IPv6 just bring a Little Reverse Proxy which is 6to4 capable.

We have one Customer with some nice gear from a not named ADC vendor here(Best in Gartners Magic Quadrant) , which is doing quite fine with this stuff. Besides, we loadbalance the Web Access across more than one Core Server, because we all know, PRTG Web Interface is getting slow above a certain number of sensors.

So for example our Customer is working via prtg.domain.com which get loadbalanced accross 3 Core/Failover Server Installations. Since Administration is only allowed via the Primary, we defined prtg-admin.domain.com to get directly to the Primary machine. with this technique we are able to handle user load AND the IPv6 Issue :) because in the backend the PRTG Installation is still ipv4 but the Access for Users is dualstack with ipv6 reachable

Sorry for typos it is late already but saw this article

Greetings Michele

I would love to see the Web GUI being available on IPv6.

We need the Web GUI to be available on IPv6

Hello Graham,
thank you for your post.

I'm afraid that this isn't currently an option. You may want to refer to Michele's contribution:

• 6to4 Reverse Proxy

Best Regards,
Luciano Lingnau [Paessler Support]

We are trying to make use of the port 5050 push sensor feature, and doing that through nat will be a real nuisance. There is really no excuse to not support ipv6 in 2017. Please fix this.

Hello Alan, thank you for your reply.

The socket created by the HTTP Push Data Advanced Sensor is completely separated from the webserver and is done by the PRTG Probe, not Core. However, the HTTP Push Data Advanced Sensor is also not IPv6 ready at the present time, but we are aware of this limitation.

Best Regards,
Luciano Lingnau [Paessler Support]

+1

I just started deploying IPv6 on my 110+ site network, I would also like to be able to access the website over IPv6.

It's now August 2017. I decided to give PRTG a go. It all fell apart once I eliminated IPv4 from my testserver. Come on, IPv6 is here to stay, you better get used to it. Sadly, being a newcomer I can't upvote any of the prior comments atm.

Hello Ximalas,
thank you for your reply.

There may come a point where the current webserver engine is replaced, that could mean that a new webserver with ipv6 could be implemented, but we're unable to provide any details/confirmation at this point.

Best Regards,
Luciano Lingnau [Paessler Support]

So we finally get the real reason why, your webserver engine doesn't support it... I think it is time to upgrade.

As a (temporary?) workaround, you can use Windows Built-in Portproxy to create an IPv6 TCP listener and forward the request to the IPv4 address of the PRTG Core Server.

Execute this on the PRTG Core Server:

netsh interface portproxy add v6tov4 listenaddress=<IPv6_address_PRTGServer> listenport=443 connectaddress=<IPv4_address_PRTGServer> connectport=443
netsh interface portproxy add v6tov4 listenaddress=<IPv6_address_PRTGServer> listenport=80 connectaddress=<IPv4_address_PRTGServer> connectport=80

Don't forget to open the ports in your Windows Firewall (allowing "PRTG Server.exe" is not enough, since that Program only support IPv4, remember?). Also check the "IP Helper" Windows Service is started.

If the Webserver Engine ever is going to support IPv6, you can remove this configuration to prevent port conflicts, with:

netsh interface portproxy delete v6tov4 listenaddress=<IPv6_address_PRTGServer> listenport=443
netsh interface portproxy delete v6tov4 listenaddress=<IPv6_address_PRTGServer> listenport=80

To check the settings:

netsh interface portproxy show all

Listen on ipv6:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
<IPv6_address_PRTGServer> 443         <IPv4_address_PRTGServer>     443
<IPv6_address_PRTGServer> 80          <IPv4_address_PRTGServer>     80

Kind regards,
Robert

Thanks for sharing RGlintmeijer!

Best regards, Felix

Almost mid 2018 and no IPv6 support.

Almost mid 2018 and a clunky and slow almost inusable WebGUI. Maybe PRTG could learn something from Grafana?

We are already thinking on moving to something better supported. It's a shame, we really liked the old PRTG.

Just my 2 cents

IPv6 is here to stay, and some technologies are only available on IPv6. If you were to use IIS as your web engine the service could be bound to the IP4 or IPv6 interface. PRTG needs modern protocol support.

July 2020, I am using the newest PRTG Network Monitor 20.2.59.1689

There is no IPv6-support for the PRTG-web-gui. I use a frontend reverse proxy under Debian which makes the transition.

PRTG Server cannot be reached by IPv6 at the moment but every Windows Server has a PortProxy-Component and it works here in my home lab wiht the 100 Sensor Free Version. I use that because my FTTH-Carrier does not assign a public IP (only a 100.75.x.x) but a public IPv6 Address. So i have to find a way to make PRTG reachable via IPv6. Configure a PortProxy on your Windows Server with PRTG installed:

netsh interface portproxy add v6tov4 -listenport=443 -connectaddress=127.0.0.1 -connectport=443 -protocol=tcp

This tells windows CoreOS to listen on and IPv6-Address on Port 443 and forward all pakets to the IPv4 Address 127.0.0.1:443

Be aware, that this only works for “Hostnames”. You cannot use a Browser and connect to "https://[fe80:6020:13fa:d300:a564:4953:16:2278]:443" because the HTTP "302 Moved"-Redirect will point to "https://[fe80:443/?". It looks like PRTG is parsing the "HostHeader" of the initial request to form the redirect and does not allow IPv6 Addresses here. The Browser does not understand that and Edge tells me [ERR_INVALID_REDIRECT]. So add a AAAA-Record to your DNS-Zone or Hosts-File

Frank

What is current status? I am currently considering adding public IPv6 address to our PRTG server. Then it would be nice for clients to be able to access it through IPv6 too. I do not think that is good to have services listening only on IPv4.

Hi there,

IPv6 for the webinterface is something we will address with the new webserver when it is fully released.

Please bear with us that we cannot tell you an exact ETA at the moment, but we are making good progress there.

Kind regards,
Felix Saure, Technical Support Team