Evening chaps... I've just installed a 2820 (non-wireless version) at work to replace the cheap and nasty modem/router that we had on our ADSL backdoor, as it kept dropping the connection or would stop responding on certain ports. Our frontdoor is a 10Mb sync connection to a corporate WAN... ISA'd and Smoothwall'd etc. We have 2x DHCP and 2x DNS servers handling the network, so the 2820 doesn't have to handle any of this.

Got the 2820 in and setup and on the whole it works well. Connection hasn't dropped once since I put it in, and the bits that are working are doing so in a much more reliable way than they have with any other piece of hardware over the past 2 years... HOWEVER... I can't for the life of me get VNC & a few other services to work thru the router, external > internal.

Here's the layout and details of what works and what doesn't:

Open port > Local machine > status (local machine OS) datatype

443 > 172.16.96.X3 > OK (Win2003) webdav over https
110 > 172.16.96.X4 > OK (Win2003) pop
25 > 172.16.96.X4 > OK (Win2003) smtp
8383 > 172.16.96.X4 > OK (Win2003) http
80 > 172.16.96.X9 > OK (FreeBSD) http
2083 > 172.16.96.X9 > OK (FreeBSD) https
2087 > 172.16.96.X9 > OK (FreeBSD) https
20870 > 172.16.96.X9 > OK (FreeBSD) ssh
1755 > 172.16.96.X5 > OK (Win2003) mms
554 > 172.16.96.X5 > OK (Win2003) mms
1024-5000 > 172.16.96.X5 > OK (Win2003) mms
5004-5005 > 172.16.96.X5 > OK (Win2003) mms
5900 > 172.16.96.XX6 > FAIL (to RealVNC Server on WinXP)
59000 > 172.16.96.X > FAIL (to VineVNC Server on OSX-Server)
59001 > 172.16.96.X > FAIL (to VineVNC Server on OSX-Server)

If I go back to my old router, flakey as it is, ALL the above work fine, so I know it isn't an issue with the machines or any other infrastructure between them and the Draytek. If I try everything locally on the LAN side, everything works. We're just using WAN1 for the net connection. DHCP is set to relay on to our main DHCP server. For the failed connections, I've tried putting each machine in DMZ... no joy. I've disabled everything firewall/filter wise, and turned off all DoS protection and all the VPN stuff as won't be used anyways to try and find any setting that could be causing the issues... but nada.

If I run Data Flow monitor, I get nothing showing up for attempts to contact the fails above, but get everything showing up fine for the others.
If I check NAT Sessions, everything is listed, including the fails.

I've fixed modulation as specified by ISP (Plusnet) to G.DMT (recommendation for issues on other models). WAN1 IP is static. Internet access thru it from internal network is fine...

All local machines respond to ping diagnosis from the router's web interface (which is on port 82).

Model Name : Vigor2820
Firmware Version : 3.3.2.2_232201
Build Date/Time : Aug 3 2009 11:13:50
ADSL Firmware Version : 232201_A Annex A

Suggestions??! Issue appears to be solely VNC related...

5900 > 172.16.96.XX6 > FAIL (to RealVNC Server on WinXP)
59000 > 172.16.96.X > FAIL (to VineVNC Server on OSX-Server)
59001 > 172.16.96.X > FAIL (to VineVNC Server on OSX-Server)

We've got many 2820s running VNC through port forwarding, but if it helps, we usually find having VNC ports public facing is a security risk too far - have you thought of setting a VPN for the users who need VNC access instead? You could then use the internal IP addresses for access.

One other thing - check the "open ports" in the firewall section of the 2820 - have you perhaps got a duplicate in there which clashes with the NAT ports?

Trying doing a config backup, then default it, re-enter your WAN stuff but only insert the VNC NAT. Then try the VNC and see if it works. Have come across a limit on the NAT rules if the VNC isn't near the top. Maybe fluke but have had that in the past.

@greenfrog - just using default ports in "open ports" as last resort... tried non-defaults port forwarding already and got nowhere. VPN not an option... too many non-savvy folks will be using the connection sadly otherwise that'd be the plan.

@loz - shall give that a shot tomorrow... ta!

I would concur with Greenfrog about the VPNs.... It sholdn't be too painful to train the users to click a VPN shortcut on a desktop...or equipment with routers to do it for them.