This error is commonly due to Java security or TLS settings but there is a second issue with forwarded ports that also causes it.
One would assume if you can get to the interface successfully via port 80/443 that all would be well but it's not enough.
Actually a port scan shows the following ports are open on the DSR:
PORT STATE SERVICE 80/tcp open http 443/tcp open https 2068/tcp open advocentkvm 3211/tcp open avsecuremgmt 3871/tcp open avocent-adsap 8192/tcp open sophos
You could forward all above ports but for normal functionality they are not required unless you are using the Avocent software I believe.
Forward these ports to your private IP of the Avocent DSR:
An example in iptables of how to forward the ports:
-s 192.168.5.4/32 #this is the only public IP that can access it (you can do away with this line if you want any remote IP to have access but for security this is recommended. I find the unit itself tends to crash from attacks/hacking attempts when left wide open to the public.
iptables -A PREROUTING -t nat -s 188.8.131.52/32 -d 184.108.40.206/32 -p tcp -m multiport --dports 80,443,2068,8192,3871,3211 -j DNAT --to 192.168.10.5
The same portforwarding can also be achieved with OpenSSH like this:
*Replace 192.168.10.5 with the NAT IP of your Avocent DSR unit
ssh -L 80:192.168.10.5:80 -L 443:192.168.10.5:443 -L 2068:192.168.10.5:2068 -L 8192:192.168.10.5:8192 email@example.com
ssh -L 80:$internalip:80 -L 443:$internalip:443 -L 2068:$internalip:2068 -L 8192:$internalip:8192 user@$remoteip
avocent, dsr, kvm, ip, solutionthis, commonly, tls, settings, forwarded, ports, linux, automatically, forwarding, nat, interface, successfully, via, scan, tcp, http, https, advocentkvm, avsecuremgmt, adsap, sophos, functionality, software, iptables, recommended, tends, attacks, hacking, attempts, prerouting, multiport, dports, dnat, portforwarding, achieved, openssh, ssl, user, remotehost, realtechtalk, avocent_unable_to_load_resource_avctvideojar, articles, avocent_, _kvm_java_icedtea_viewer_,