Can only web browse

bluestreek

I set up open vpn on my linux vps and I connect from my windows computer.

Web browsing works fine and my ip changes ok. The problem is when I try to connect to a league of legends game or a teamspeak server the connection fails when connected to the vpn.

I tired some settings to resolve this but nothing is working.

net.ipv4.ip_forward = 1

iptables -A FORWARD -i tun+ -o venet0 -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j MASQUERADE

I tried using the OpenVPN access server and just the normal version.

I am running CentOS 6.

Any help would be great! Thanks.

maikcat

in VZ container the NAT rule needs to be setup a little different..

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o venet0 -j SNAT --to-source 1.2.3.4   1.2.3.4 is openvz real ip

Michael.

Traffic

@Michael .. out of curiosity, why is that .. does a VZ container not support Masquerading ?

maikcat

The difference between the SNAT & MASQ is simply...

http://www.netfilter.org/documentation/HOWTO//NAT-HOWTO-6.html

You want to do Source NAT; change the source address of connections to something different. This is done in the POSTROUTING chain, just before it is finally sent out; this is an important detail, since it means that anything else on the Linux box itself (routing, packet filtering) will see the packet unchanged. It also means that the `-o' (outgoing interface) option can be used.

Source NAT is specified using `-j SNAT', and the `--to-source' option specifies an IP address, a range of IP addresses, and an optional port or range of ports (for UDP and TCP protocols only).

## Change source addresses to 1.2.3.4.
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4

## Change source addresses to 1.2.3.4, 1.2.3.5 or 1.2.3.6
# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to 1.2.3.4-1.2.3.6

## Change source addresses to 1.2.3.4, ports 1-1023
# iptables -t nat -A POSTROUTING -p tcp -o eth0 -j SNAT --to 1.2.3.4:1-1023

Masquerading

There is a specialized case of Source NAT called masquerading: it should only be used for dynamically-assigned IP addresses, such as standard dialups (for static IP addresses, use SNAT above).

You don't need to put in the source address explicitly with masquerading: it will use the source address of the interface the packet is going out from. But more importantly, if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.

## Masquerade everything out ppp0.
# iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

since i am not a VZ guru but i have a feeling that this might be related...

if the link goes down, the connections (which are now lost anyway) are forgotten, meaning fewer glitches when connection comes back up with a new IP address.

Due to the fact that this is a container we are talking about and NOT a full based VM (like KVM/VMware)
the NIC is controlled by the host OS , maybe the link is not stable causing the MASQ rule to flush its state.. ?

Michael.

Traffic

Thanks Michael 8-)

maikcat wrotethe NIC is controlled by the host OS

this makes sense ..

If the physical NIC is also shared between other containers, perhaps iptables cannot determine the IP address to masquerade and so you must implicitly specify which address for snat ..