[SOLVED] Help with port forwarding

[blknit 0]

I've never been able to make it work the remote port forwarding

I'm on a Linux box with iptables disabled connecting to the german server (53 udp)

i'm listening on port 17019 with netcat and doing at the same time an online port scanning on this website http://www.t1shopper.com/tools/port-scan

The result is always the same "78.159.121.135 isn't responding on port 17019 ()."

I removed and re-added the port from the user panel without luck

Any idea ?

Thank you

[Staff 9972]

@blknit

Hello!

Just checked that port 17019 is correctly forwarded for your account and that port forwarding on Omicron works as expected. Are you running any software firewall on your Linux box?

Kind regards

AirVPN admins

[blknit 0]

I have no firewall

sudo iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Only for information.. i have two tun device, tun0 used by my openvpn server and tun1 dynamically created when i connect to Airvpn. Could this be a problem ?

Thank you

[Staff 9972]

blknit wrote:

Only for information.. i have two tun device, tun0 used by my openvpn server and tun1 dynamically created when i connect to Airvpn. Could this be a problem ?

Thank you

Hello!

Can you please send us the kernel IP routing table (netstat -nr) and the status of all your interfaces (ifconfig -a) when you are connected to a VPN server and you have both tun0 and tun1 (feel free to delete privacy weakening info)?

Kind regards

AirVPN admins

[blknit 0]

[file name=netstat.txt size=1053]http://airvpn.org/media/kunena/attachments/legacy/files/netstat.txt[/file]

[file name=ifconfig.txt size=1913]http://airvpn.org/media/kunena/attachments/legacy/files/ifconfig.txt[/file]

Thank you

netstat.txt

ifconfig.txt

[blknit 0]

I did other tests :

Linux distro (ubuntu) without firewall --> rpf not working

Win7 + win firewall --> rpf works

Other linux distro (arch) without firewall ---> rpf not working

Best regards

[Staff 9972]

blknit wrote:

I did other tests :

Linux distro (ubuntu) without firewall --> rpf not working

Win7 + win firewall --> rpf works

Other linux distro (arch) without firewall ---> rpf not working

Best regards

Hello!

Thank you very much for those tests. They show that the problem is not on the VPN server side. We must concentrate on Linux distros. What version of Ubuntu and Arch are you using?

Kind regards

AirVPN admins

[blknit 0]

I'm using Ubuntu 11.10 (Oneiric) on the main pc and Arch on the old pc with the latest update (arch is a rolling release distro).

Thank you

[Staff 9972]

blknit wrote:

I'm using Ubuntu 11.10 (Oneiric) on the main pc and Arch on the old pc with the latest update (arch is a rolling release distro).

Thank you

Hello!

Probably you have already considered the following, anyway: according to your network configuration, it may be necessary to enable IP forwarding on your box. Usually IP forwarding is disabled by default in the kernels of the distros,, and surely it is disabled in Ubuntu 11.10.

You can do that, in order to test, on the fly:

echo 1 > /proc/sys/net/ipv4/ip_forward

or

sysctl -w net.ipv4.ip_forward=1

Looking forward to hearing from you.

Kind regards

AirVPN admins

[blknit 0]

Ip forwarding is already enabled on both pc

$ cat /proc/sys/net/ipv4/ip_forward

1

Thank you

[Staff 9972]

blknit wrote:

Ip forwarding is already enabled on both pc

$ cat /proc/sys/net/ipv4/ip_forward

1

Thank you

Hello!

Thanks. Can you please also check that ufw is disabled, or its status?

Kind regards

AirVPN admins

[blknit 0]

Sure

$ sudo ufw status

Status: inactive

$ sudo iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

$ sudo iptables -t nat -L

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

$ sudo iptables -t mangle -L

Chain PREROUTING (policy ACCEPT)

target prot opt source destination

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy ACCEPT)

target prot opt source destination

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

Chain POSTROUTING (policy ACCEPT)

target prot opt source destination

Thank you

[blknit 0]

so... no way to make rpf working on linux client ?

[gzz 0]

It seems that I'm also suffering from the same problem with my Debian box and haven't been able to resolve it either. I'm not sure if this helps any further on issue resolution but here is what I have been able to diagnose so far.

It seems that port forwarding on server side is working and with tcpdump I can see that my box receives SYN packets from the server but I'm accumulating connections stuck in SYN_RECV state (ie. my box for some reason doesn't ACK the connection attempt) and the actual connection is not established.

tcp 0 0 10.5.x.x:20124 89.149.x.x:64676 SYN_RECV

tcp 0 0 10.5.x.x:20124 89.149.x.x:19634 SYN_RECV

tcp 0 0 10.5.x.x:20124 89.149.x.x:57239 SYN_RECV

Iptables rules doesn't seem to have any affect on this one as long as I'm not explicitly rejecting the connection to my inbound port. Also I have tried to tweak my TCP settings using tips and tricks I have found from the Internet but I haven't found them to have any benefit in this problem.

Cheers!

[Staff 9972]

@gzz

Hello!

We are working on that.

Packets arte properly forwarded to clients, but some Linux boxes (including Ubuntu and Debian distros) do not answer to those packets. Windows (any version), Mac OSX and Android do not have this problem. We will keep you posted.

Kind regards

AirVPN admins

[blknit 0]

It's working now.

Thank you

[gzz 0]

I second blknit, fix confirmed.

Thanks!

[Staff 9972]

blknit wrote:

It's working now.

Thank you

Hello!

Excellent! It was our problem on SNAT. While Windows and Max OSX appear to accept to send replies inside the tunnel to incoming connections (TCP) from the entry-IP address of VPN servers (further investigations on this are in progress, since this does not appear a "good" behaviour, because it seems to override on the client side the push route commands sent by our server), Linux does not. Therefore listening services (behind our servers) based on Win and Mac worked.

These facts put us on the wrong track, pointing us to a client side problem, while it was not, and causing the huge delay in solving the problem.

Now incoming connections packets arrive from the exit-IP of the servers, solving the root of the problem.

Linux behaviour is the "correct" behaviour, in the sense that it fully complies to OpenVPN directives and commands sent from our servers.

Please do not hesitate to contact us for any further information.

Kind regards