Server rentals :: NFOservers.com

I did a tcpdump on eth0 while connecting and attempting to ping google(74.125.227.146 in this case), I can see the traffic using my correct source address, ie my real ip for my home connection. I am not sure what is stopping it from being returned to the tunnel?

I also included a ufw log that show the tun0 adapter being allowed and packets sent to eth0.

I really appreciate your (or any else's) assistance!


Paul

EDIT: Can't seem to find the pm option?! So I will email you the logs John

Searching for information on this tonight, I found consistent advice that this:


needs to be replaced with:


It's not clear why, buy it seems that SNAT is needed for OpenVZ, and MASQUERADE is needed for Xen.

Tried removing the SNAT rules and entering the MASQUERADE rule but the same problem, no forwarding seems to be happening

I'm having the same issue. I have even copied the same configuration I use on other xen vps servers which works fine there. I have tried two different nfoservers vps servers and neither work. Something is wrong at the host level.

OpenVpn connects, packets hit the proper iptables rules and everything seems to be fine except nothing comes back through tun0 and TX packets are at 0.

paulg1981's tcpdump data showed that:

* The request was arriving to the VDS properly via its tunnel and the virtual network adapter
* The OS was making the request to the external site properly via the virtual network adapter (using its correct public IP)
* The external site's response was arriving properly via the virtual network adapter
* The response was *not* going back out over tun0 to the OpenVPN client. In fact, the OS inside the domU was responding that the TTL was being exceeded in-transit.

Since tun0 is an internal network construct, this suggests that the forwarding path is broken somehow in the domU (but the dom0 is working fine).

My next step in troubleshooting this for him is to try to replicate the problem myself, and then do more extensive dumps and tests.

Ok, I spent some time testing and determined the problem. Enter this line for a quick fix -- you'll see everything suddenly start working as it should:


The problem was stemming from the fact that we set the TTL to 2 on all inbound packets, in order to prevent routing loops (which can happen if the customer turns off his VDS, causing inbound packets suddenly start bouncing around). Such loops can amplify the effects of DDoS attacks. As a result of the low TTL, your VDS was discarding the inbound packets instead of forwarding them to the VPN client. Raising the TTL by one is enough to take care of this.

I will also look into whether it would be feasible to remove our TTL-reducing rule by finding another way to mitigate the DDoS threat.

I've changed the ruleset so that the workaround I gave in my last post should no longer be needed. OpenVPN should now work out of the box with standard setup instructions.

Thanks again for all your investigation in this issue. I can confirm that openvpn works out of the box now.