Port becomes unreachable after a certain amount of time

[StealthySausage 1]

Hi there, I'm using a QNAP TS-253A router with Transmission installed on it and after a certain period of time the peer port becomes unreachable. I have ensured that Transmission's listening port matches the one in the Forwarded Ports section of AirVPN's Client Area. When I first connect to the VPN server using the VPN client built in to the NAS, the Transmission port test is successful, but after some period of time passes (between 6 hours - 2 days) the port becomes unreachable. If I then disconnect and reconnect to the VPN server, the port becomes reachable again. The image below should illustrate my setup.

 

[zhang888 1066]

This might be a combined issue of multiple wrong settings.

For example, binding your applications to a static IP instead of an interface is wrong, that IP is dynamic and will change if you connect

to a new server. You should bind it to your tun0 interface instead. So if your VPN client reconnected and got a new IP, this issue may happen.

 

Other settings you should check are the firewall settings, if you see 2GB in your statistics but in reality you transferred more, you might

have a leak and traffic could go via your WAN interface, which will obviously not work with your previous port you forwarded for the VPN.

[StealthySausage 1]

The VPN didn't reconnect during those 2 days, as you can see in the uptime in the VPN client statistics. Even if it did reconnect, it assigns the same local IP for the tunnel traffic. As I said, when the port mysteriously closes I have to reconnect to the VPN server to get the port to open again, so in reality if the VPN client reconnects, it actually fixes the issue temporarily. The IP never changes when this happens. If something is wrong with my settings, then why does the port open for hours in the first place?

 

I think the 2GB thing is a bug in the current version of the NAS firmware. It transfers past 2GB, but doesn't display it in the stats but the traffic is still on the VPN. When the port closes, the traffic is still running through the VPN but the peer port stops accepting connections.

[zhang888 1066]

The GUI pages of various routers are not the best tools for debugging issues.

You can post your OpenVPN connection logs and tcpdump logs on that port (tcpdump should be available as an optware ipkg).

[StealthySausage 1]

I've got the OpenVPN log running now, which I had to modify the config file for manually on the NAS, as there is no GUI setting to enable it.

 

I've also downloaded TCPDump for Entware-ng, but am unsure as to what command line switches to use to just get the info we need.

[zhang888 1066]

tcpdump -i tun0 'port your_port'

 

Then check the incoming packets when you are testing the port.

[StealthySausage 1]

So I have to run that and ouput it to a log for several hours until the port closes? Hmm, it may get rather large. Here's what I captured in a window when the port test is successful in Transmission (it hasn't closed yet). The interface turned out to be tun2001. The port in question is censored with 5 asterisks.

 

 

[~] # tcpdump -i tun2001 'port *****'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun2001, link-type RAW (Raw IP), capture size 262144 bytes
05:44:18.148909 IP vm4.transmissionbt.com.59140 > 10.4.49.116.*****: Flags [S], seq 3655541719, win 29200, options [mss 1352,sackOK,TS val 2871587296 ecr 0,nop,wscale 7], length 0
05:44:18.148977 IP 10.4.49.116.***** > vm4.transmissionbt.com.59140: Flags [S.], seq 128236400, ack 3655541720, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
05:44:18.205937 IP vm4.transmissionbt.com.59140 > 10.4.49.116.*****: Flags [.], ack 1, win 229, length 0
05:44:18.206039 IP vm4.transmissionbt.com.59140 > 10.4.49.116.*****: Flags [F.], seq 1, ack 1, win 229, length 0
05:44:18.206844 IP 10.4.49.116.***** > vm4.transmissionbt.com.59140: Flags [.], ack 2, win 229, length 0
05:44:18.245026 IP 10.4.49.116.***** > vm4.transmissionbt.com.59140: Flags [F.], seq 1, ack 2, win 229, length 0
05:44:18.301959 IP vm4.transmissionbt.com.59140 > 10.4.49.116.*****: Flags [.], ack 2, win 229, length 0
^C
7 packets captured
7 packets received by filter
0 packets dropped by kernel

 

[zhang888 1066]

means that your tun device received this packet from outside and everything works as usual.

You should run this when your port is not functioning as you claim.

[StealthySausage 1]

means that your tun device received this packet from outside and everything works as usual.

You should run this when your port is not functioning as you claim.

Okay, as expected the port has closed again within 2 days. When I run the Transmission port test, it fails and absolutely nothing is output to TCPDump related to the test when monitoring the server port. However, peer connection attempts are still apparently being made:

 

22:39:12.900457 IP ***.***.***.***.6881 > 10.4.49.116.*****: UDP, length 65
22:39:12.900573 IP 10.4.49.116.***** > ***.***.***.***.6881: UDP, length 47
22:39:22.557237 IP ***.***.***.***.6881 > 10.4.49.116.*****: UDP, length 65
22:39:22.557355 IP 10.4.49.116.***** > ***.***.***.***.6881: UDP, length 47
22:39:23.311542 IP ***.***.***.***.6881 > 10.4.49.116.*****: UDP, length 65
22:39:23.311657 IP 10.4.49.116.***** > ***.***.***.***.6881: UDP, length 47

There are no flags, so I guess that means these peers are failing to connect?

 

Here's the OpenVPN Log, but there doesn't appear to be anything suspicious in that:

 

openvpn.log.txt

[zhang888 1066]

UDP keeps working. Don't use the Transmission test, all those tests are unreliable. Open a terminal and type

nc -vvvv air_exit_ip port

 

This should initiate a connection, then check tcpdump.

[StealthySausage 1]

UDP keeps working. Don't use the Transmission test, all those tests are unreliable. Open a terminal and type

nc -vvvv air_exit_ip port

 

This should initiate a connection, then check tcpdump.

[~] # netcat -vvvv 84.39.117.57 *****
Warning: Inverse name lookup failed for `84.39.117.57'
^CExiting.
Total received bytes: 0
Total sent bytes: 0

Nothing in TCPDump except more UDP peer connections.

 

If nobody else has reported an issue with ports closing randomly, I guess it can't be the VPN's fault. Must be something to do with the NAS?

 

Edit: As soon as I disconnect then reconnect to the VPN, the netcat command works:

 

 

[~] # netcat -vvvv 84.39.117.57 *****
Warning: Inverse name lookup failed for `84.39.117.57'
84.39.117.57 ***** open
^CExiting.
Total received bytes: 0
Total sent bytes: 0

 

[~] # tcpdump -i tun2001 'port *****'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun2001, link-type RAW (Raw IP), capture size 262144 bytes
02:55:24.159797 IP ********-******-*-*-*****.**-*.*****.*******.***.***** > 10.4.49.116.*****: Flags [S], seq 773864252, win 29200, options [mss 1352,nop,nop,sackOK,nop,wscale 7], length 0
02:55:24.159844 IP 10.4.49.116.***** > ********-******-*-*-*****.**-*.*****.*******.***.*****: Flags [S.], seq 2762126117, ack 773864253, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
02:55:24.204601 IP ********-******-*-*-*****.**-*.*****.*******.***.***** > 10.4.49.116.*****: Flags [.], ack 1, win 229, length 0
^C
3 packets captured
3 packets received by filter
0 packets dropped by kernel

 

So it's working for now, until the port closes again.