ANSWERED port forwarding : local port setting seems to be ignored

[Snaky81 0]

Hello

I use airvpn on my linux server, and I want to be able to ssh it from the outside. Since the dyndns I previously had now points to the VPN exit address, I try to configure a port forwarding on airVPN to reach my SSH server through the vpn interface.

So I added a new forwarded port in my client area, and I set the local port to 22, where the sshd listen (on all interfaces).
However when I do the "test open" check, it fails with a "connection refused (111)" error.

In order to troubleshoot this, I ran a tcpdump on my server and here is the output :

 

sudo tcpdump -i tun0 'port 22 or port 9935'
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:09:22.200072 IP 142.93.172.65.44342 > 10.27.159.223.9935: Flags [S], seq 2349996053, win 64240, options [mss 1355,nop,nop,TS val 179392932 ecr 0,nop,wscale 7], length 0
17:09:22.200111 IP 10.27.159.223.9935 > 142.93.172.65.44342: Flags [R.], seq 0, ack 2349996054, win 0, length 0

10.27.159.223 is the ip of the vpn interface, and 9935 is the forwarded port that was assigned. Am I doing something wrong ?
According to the test report, it expects the connection to be made on port 22 too, but tcpdump proves it tries on port 9935 as if the "local port" setting was not working
 

  Edited ... by Snaky81

[Staff 10137]

16 hours ago, Snaky81 said:

According to the test report, it expects the connection to be made on port 22 too, but tcpdump proves it tries on port 9935 as if the "local port" setting was not working

Hello!

Thanks for the thorough report. During the current tests with your own connection, we could verify that the port re-direction on the server is correct. On the other hand, your tcpdump output is quite clear. Therefore this could be a rare bug which does not always occur. Or you might have changed the "local" field of the port (in your AirVPN account port panel) while your connection was active. In this specific case the system can not change "on the fly" the pre-routing rules and requires a disconnection and re-connection. Please let us know whether the problem re-appears and/or persists even after a disconnection / re-connection.

Kind regards
 

[Snaky81 0]

Indeed reconnecting the session fixed it, thank you for the support