Hello folks,

Have been running a Vigor 2800 with the 2.7_E38 firmware quite happily for six or seven months. It has a clean 'out-of-the-box' configuration, except for a NAT rule that I use to pass inbound RDP traffic on 3389 through to our Windows terminal server. There are no further restrictions on access to 3389 configured, but as of the last couple of days the Draytek seems to be preventing the passthrough of inbound connections.

I can get into the Windows terminal server fine from within the network, or down a dial-in VPN, but when I point the RDP client directly at the WAN IP the NAT Active Sessions table looks like this:

---

Private IP :Port #Pseudo Port Peer IP :Port Ifno Status

---

192.168.0.5 3389 3389 [our WAN IP] 33062 3 4

and the RDP client times out.

I can't find reference to a '4' code in the Draytek documentation. Does anyone know what could be causing this and how to fix? I've tried deactivating the NAT rules, soft-rebooting the router and re-enabling them. Would power cycling the box be helpful?

Many thanks.

See what syslog reports at the time you instigate the connection.

Is there any documentation on all the status codes. So far the only one I've found only describes values 0 to 3. Rather like the top post, I've got troublesome inbound connections on a redirected port showing status code 4, and the syslog doesn't tell me anything about them apart from that they've been directed to the appropriate internal system on the appropriate port. Here are a couple of the relevant lines:

Code:

Private IP :Port #Pseudo Port Peer IP :Port Ifno Status 192.168.1.2 80 80 149.254.x.x 46846 3 4 192.168.1.2 80 80 81.2.x.x 19018 3 4

The info I've found so far is from http://www.draytek.com.au/faq/router.htm and says:

In the NAT session table form System Management -› Diagnostic Tools -› View NAT Active Sessions Table, the status values are defined as follows:

0 - › other TCP status
1 - › TCP fin incoming
2 - › TCP fin out
3 - › TCP fin closing

I'm also seeing the occasional status code "6", but it doesn't appear to be connected with the problem I'm seeing...

It might be related to the router's slight reluctance to connect hosts to the outside world when Bind-to-MAC is enabled and the host at the given IP address doesn't have the MAC to which that IP address is supposedly bound. I didn't have strict binding enabled, but i did have some MACs from older machines in the bindings table that didn't match the MACs of the current machines. Why it didn't affect ssh or https is a mystery.