Recently, during VPN server configuration the one thing that I've faced is - I don't have internet access connecting through my VPN server. Actually I use the VPS(Debian 8 ), where I've installed a VPN. The client connects normally I've used the trace route command to detect where traffic stops, and obviously it stops at my VPN server. I really don't know how to deal with it. Anyone help me please:) Here's my Server config and Client config. And yes my client side is Windows 7 and 10.

Server config.

port 1194
proto udp
dev tun
ca ca.crt
cert server.crt
key server.key  # This file should be kept secret
dh dh2048.pem
ifconfig-pool-persist ipp.txt
push "redirect-gateway def1 bypass-dhcp"
push "dhcp-option DNS"
push "dhcp-option DNS"
keepalive 10 120
user nobody
group nogroup
status openvpn-status.log
verb 3

Client config. Note: Server's IP is hidden.

dev tun
proto udp
remote 107.155.1x4.1x2 1194
resolv-retry infinite
ca "C:\\OVPN\\ca.crt"
cert "C:\\OVPN\\client1.crt"
key "C:\\OVPN\\client1.key"
ns-cert-type server
verb 3

From client side I tried to test Google's DNS server - still it doesn't work. I think the problem lies with some of the interfaces on the server side which break outs to internet. So anyone who suggests something, just help me with useful advice.

"Add the output of the following commands please: sysctl net.ipv4.ip_forward, iptables-save, ip route show. On the client maybe: route print. – rda "

1) The outuput for sysctl net.ipv4.ip_forward is

net.ipv4.ip_forward = 1

2) The output for ip route show is dev tun0 proto kernel scope link src via 10.8.02 dev tun0
default dev venet0 scope link

3) And Outuput for iptables-save is

:PREROUTING ACCEPT [241673:29858781]
:INPUT ACCEPT [232866:29385621]
:FORWARD ACCEPT [8803:472884]
:OUTPUT ACCEPT [250884:4018010]
:POSTROUTING ACCEPT [259688:40653794]
:INPUT ACCEPT [232866:29385621]
:FORWARD ACCEPT [8804:472884]
:OUTUPUT ACCEPT [250884:40180910]
:PREROUTING ACCEPT [20668:1262348]
:POSTROUTING ACCEPT [14826:1006759]
:OUTPUT ACCEPT [10970:791257]
:PREROUTING ACCEPT [241673:29858781]
:OUTPUT ACCEPT [250884:40180910]

June 11

I believe the problem lies in routing tables, I've run the command - netstat -nr , and surprisingly I've found that in my routing table I've strange IP addresess which are assigned only for VPN using.**

Here, take a look:

Kernel IP routing table(Note: the routing table parameters go as following in column(!), Ex: the routing table's IP take all first parameters from first column. And last three parameters MSS Window irtt are the same for each value of routing table.

Destination face un0 un0 enet0 

Gateway face un0 un0 enet0 

Genmask face un0 un0 enet0 

Flags face UH un0 UG un0 U enet0 

MSS Window irtt face 0 0 0 un0 0 0 0 un0 0 0 0 enet0

June 15

Hey buddy! Thanks for your reply again!

the output for ip route show is: dev tun0 proto kernel scope link src via dev tun0 default dev venet0 scope link 

the output for following command on VPS ip route get is(Note: IP address is hidden): dev venet0 src 107.155.1x4.1x2 
    cache mtu 1500 advmss 1460 hoplimit 64

On the client side - I used this command route print - I got hell of a big page of IP addresses, but I don't know what is important here to solve this this problem...

What are the next steps?

Big thanks to you again for your help, really

Update 15 June

So here's the output for command route print on windows client:

IPv4 Route Table
Active routes:
Network address        Subnet mask        Gateway          Interface   Metric
     20         On-link    306         On-link    306         On-link    306         On-link    276         On-link    276         On-link    276         On-link    266         On-link    266         On-link    266         On-link    276         On-link    276         On-link    276         On-link    276         On-link    276         On-link    276         On-link    306         On-link    276         On-link    276         On-link    276         On-link    266         On-link    306         On-link    276         On-link    276         On-link    276         On-link    266
Permanent routes:

Update June 17

Hey buddy, I've tried using those commands which enable NAT on server, unfortunatelly again it doesn't work. The output for ip route show is the same like it was before: dev tun0 proto kernel scope link src via dev tun0
default dev venet0 scope link

Those commands that you gave me, were running smoothly, but didn't bring any results. So, new IP route just doesn't appear in output! I tried adding the same route different ways, even changed the mask from /16 to /24, still nothing.

The only one important thing that made me feel strange is - I've ran my OVPN Gui at client side, and I know that internet doesn't work, and what I see, from the start my Facebook page starts to load, but other ones like google.com or linkedin.com - or any other website - they just don't open...

Some minor things about my VPS provider, at FAQ page they tell the following things:

    Do you support TUN/TAP? IPSEC?

    Yes, TUN/TAP and IPSEC are enabled on all VPS by default.**

What kind of virtualization is offered/used?

We utilize OpenVZ on our infrastructure. If you require KVM virtualization we recommend SpeedyKVM.**

What this problem may be And how we can overcome this?

Again big thanks to you!

  • I believe, that Yes. I used the OpenVPN guide from digital ocean ( digitalocean.com/community/tutorials/… ) "sorry if i can't put here external links". So by this guide I've configured the IP masquerading, and some policies to allow ipv4 traffic to go through the VPN server. By default, when I connect to VPN from any computer, VPN assigns the same IP address to each client ( something like this) but anyway, I have connection only between client-VPN. What Can I do here?
    – woozyman
    Jun 10, 2016 at 11:28
  • I believe that no, I don't know any VPS firewall rules...How Can I find them and change if so?
    – woozyman
    Jun 10, 2016 at 11:51
  • It is dependent on your VPS provider - Amazon as a web interface for instance. Add your VPS provider to the post, please. Jun 10, 2016 at 11:52
  • I use the www.wable.com
    – woozyman
    Jun 10, 2016 at 11:56
  • I can send you the logs from VPS, let's ping something what's important, so I will know about what to talk to them
    – woozyman
    Jun 10, 2016 at 12:01

1 Answer 1


You have to enable NAT on the server.

SNAT for static IP address:

iptables -t nat -A POSTROUTING -s -o <if> -j SNAT --to <ip>

Or if you have a dynamically assigned IP address use MASQUERADE (slower):

iptables -t nat -A POSTROUTING -s -o <if> -j MASQUERADE


  • <if> is the name of the external interface (i.e. venet0)
  • <ip> is the IP address of the external interface
  • Hey buddy, I tried to run this command and unfortunately I still can't break out to the internet:( What we gonna do next?
    – woozyman
    Jun 14, 2016 at 8:26
  • How we can do that?
    – woozyman
    Jun 14, 2016 at 13:45
  • @woozyman In your question you already posted the firewall configuration using iptables-save or iptables- vnL, which does not restrict anything and should not make problems. Maybe check if the routing table on your server is correct using ip route show. I noticed the missing via <gateway_ip> in the default line, which could indicate that the interface has a direct connection via cable or this might be a special circumstance for virtual hosts. The interface name venet0 could indicate that OpenVZ is used for virtualization. But I do not have any experiance with this.
    – rda
    Jun 14, 2016 at 14:24
  • @woozyman on your windows client's you can check the routing using cmd route print. Maybe check on the server if the routing is working using ip route get
    – rda
    Jun 14, 2016 at 14:30
  • Check out please my main comment box(15 June) the last message - I've left there the outputs for those commands, check this out please!:)
    – woozyman
    Jun 14, 2016 at 21:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.