I have a problem with openvpn. I have Ubuntu server and Windows client. The configuration file on server looks like:

dev tun
proto udp
port 1194
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/server.crt
key /etc/openvpn/easy-rsa/keys/server.key
dh /etc/openvpn/easy-rsa/keys/dh1024.pem
user nobody
group nogroup
verb 3
push "redirect-gateway def1"

And the config file on client machine:

dev tun
proto tcp
remote vpn.domain.com 1194
resolv-retry infinite
user nobody
group nogroup
ca ca.crt
cert marten.crt
key marten.key
verb 3

When I try to connect, everything seems to be ok. The client is connected and has an IP in the VPN range. The problem is that I'm not able to ping nor connect to the server or other clients. There is nothing suspicious in the log files. Can someone help me or provide me with working config files?

  • 3
    Maybe its: Your server is proto udp. Your client is proto tcp.
    – user199587
    Commented Feb 15, 2013 at 18:08

8 Answers 8


I too had the same issue last week. It got fixed when I changed the line in the OpenVPN server configuration file from

push "redirect-gateway def1"


push "redirect-gateway def"
  • refer to community.openvpn.net/openvpn/wiki/Openvpn23ManPage for valid options for redirect-gateway. def1 is a valid argument whereas def will likely not do anything since it not valid and should through an error message in the client log.
    – Andrew S
    Commented Oct 24, 2017 at 23:11
  • 1
    This was a solution to my problem after hours of pulling hairs off Commented Dec 15, 2021 at 3:21
  • Can you explain the difference please? What does this change do?
    – Shayan
    Commented Oct 29, 2022 at 19:18

Seems you have answered your own question:

The client is connected and has an IP in the VPN range.

Normally, the VPN clients has it's own IP range, as in your configuration (10.8.x.x). You should set up the routing on the server, so, for example, the will be masqueraded to or whatever your local intranet range is...

  • Yah, I think that was mentioned in the question... "The client is connected and has an IP in the VPN range" and his client and server configs show this as well... Commented Sep 7, 2010 at 22:06

I am 100% sure it is your firewall, because the same exact thing happened to me. If you're connected then everything is fine. It is likely that the firewall is open only for the VPN and it is denying everything else.


Do the following to clear all iptables rules:

iptables -F
iptables -X
iptables -t nat -F
iptables -t nat -X
iptables -t mangle -F
iptables -t mangle -X
iptables -P INPUT ACCEPT

Then, try to ping from the client, once it's connected. If it works, your iptables rules are blocking. You need to add rules that allow traffic from tun0 on the server.

Also, note that any services will need to be listening on all IP addresses or to be reachable over the VPN.


While changing def1 to def worked (because now the option doesn't do anything), in my case the fix was to uncomment topology subnet:

# Network topology
# Should be subnet (addressing via IP)
# unless Windows clients v2.0.9 and lower have to
# be supported (then net30, i.e. a /30 per client)
# Defaults to net30 (not recommended)
topology subnet

Note that it says the default is net30, and the recommendation is subnet.


Always check the firewalls ! I was caught out for days by windows 10 firewall. Whilst I opened all the windows, router, modem, linux firewall ports and could get an openvpn connection, I could only ping one way from a windows 10 server to a public Linux client, and not from client to server. Only after a lunchtime chat with an expert colleague (thanks Tony!) did I learn that windows 10 firewall blocks ping requests from public networks by default. To unblock go into windows 10 firewall advanced settings and enable

File and Printer Sharing (Echo Request - ICMPv4-In)

solved my problem immediately, so I post here incase anyone else gets caught out !


Check the openvpn.log file on the on server. I found that if one of the 'push "route x.x.x.x"' lines has an invalid mask for the subnet an error will be thrown in the log file and the vpn won't operate at all. The error looks non-fatal but it does indeed appear to be fatal. Try nitially removing all push route lines and see if you can ping the server side of the vpn by default. Once you can do this add in your route push lines gain.



Had the same issue, however linux -> linux. After I enabled lzo compression on client worked. You may also try to comment comp-lzo line on server.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .