Ask questions about dedicated servers here and we and other users will do our best to answer them. Please also refer to the self-help section for tutorials and answers to the most commonly asked questions.
Edge100x wrote:Does a tcpdump process monitoring eth0 tell you that any traffic is going out? If so, does it have the correct source IP (your external IP instead of an internal one)?
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
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.
* 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.
root@dedi:~# cat /etc/iptables_rules
*nat
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j SNAT --to-source xxx.xxx.xxx.xxx(My IP)
COMMIT
*filter
-A INPUT -i lo -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 873 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 1023 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 3389 -j ACCEPT
-A INPUT -p udp -m udp --dport 32400 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 32400 -j ACCEPT
-A INPUT -p udp -m udp --dport 32443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 32443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 65001 -j ACCEPT
-A INPUT -p udp -m udp --dport 65001 -j ACCEPT
-A INPUT -j DROP
COMMIT
I have also tried MASQUERADE instead of SNAT for the postrouting rule with no effect. The openvpn server has no problem connecting but no traffic is flowing over the tunnel. Just like a few years ago?
This exact config is working fine elsewhere? Please help!
If it were the same problem as before, then the workaround that I gave above would compensate for it. I double-checked, though, and we definitely don't have any machines with that old problem.
Is anything set on the Firewall tab for the VDS? Do you have any other iptables lines that may be getting in the way? Do you see anything in the system log? Have you tried a fresh Debian install and using https://github.com/Nyr/openvpn-install? Have you tried deleting the other lines and just having the SNAT one (the others aren't needed)?
Edge100x wrote:If it were the same problem as before, then the workaround that I gave above would compensate for it. I double-checked, though, and we definitely don't have any machines with that old problem.
Is anything set on the Firewall tab for the VDS?
Nothing set for firewall in the control panel. double checked
Do you have any other iptables lines that may be getting in the way?
The ones I posted are my entire config. Just to be sure I cleared everything out and entered just the SNAT rule and still no luck.
Do you see anything in the system log?
The only thing in the syslog from ovpn is successfull connections from my client.
Have you tried a fresh Debian install and using https://github.com/Nyr/openvpn-install?
Very cool resource! I went through the script and the only iptables rule it uses is the same one I already have.
Have you tried deleting the other lines and just having the SNAT one (the others aren't needed)?
Yes, to no avail.
This is so frustrating! I have double and triple checked everything (ip_forwarding, iptables, server.conf) and used the same config to reinstall openvpn on another debian machine with success. Please help!
I'm not an expert on OpenVPN, myself, having only installed it to investigate the issue discussed previously. Someone else may have more experience with it and be able to contribute here.
On our end, I can look a the version of Xen on your machine and update it to the latest version if you wish. To go that route, please open a request.
