I'm trying to set up an openvpn server on a raspberry pi to act as an endpoint for road worrier connections but the device is sitting on the network, not as the gateway of any of the machines on the network and I suspect this is the problem.

I've looked at MANY tutorials and have the vpn connection up correctly, and the client routing is OK as I can connect to the raspi via the tunnel, but if I ping anything else on the network I get request timeout's. My only difference is that I'm using a tcp connection, not a UDP one, but have adjusted the firewall rules to suite.

I have tried a number of different iptables rules, have forwarding enabled and have even installed a static route on the cyberoam to try and make this work.

My configs are as follows.


port 1194
proto tcp
dev tun

ca      /etc/openvpn/ca.crt    # generated keys
cert    /etc/openvpn/folkarch.crt
key     /etc/openvpn/folkarch.key  # keep secret
dh      /etc/openvpn/dh2048.pem

server  # internal tun0 connection IP
ifconfig-pool-persist ipp.txt
push "route"
push "route"
push "route"
#push dhcp-option DNS"
push "redirect-gateway def1"
keepalive 30 240

comp-lzo         # Compression - must be turned on at both end

status log/openvpn-status.log

verb 3  # verbose mode

client config to match, nothing much in it..



#/sbin/iptables -t nat -A POSTROUTING -s -o eth0 -j SNAT --to-source

/sbin/iptables -A INPUT -i tun+ -j ACCEPT
/sbin/iptables -A OUTPUT -o tun+ -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -s -o eth0 -j MASQUERADE
/sbin/iptables -I FORWARD -i tun0 -o eth0 -s -d -m conntrack --ctstate NEW -j ACCEPT
/sbin/iptables -I FORWARD -i tun0 -o eth0 -s -d -m conntrack --ctstate NEW -j ACCEPT
/sbin/iptables -A INPUT -i eth0 -m state --state NEW -p tcp --dport 1194 -j ACCEPT
/sbin/iptables -A FORWARD -i tun+ -j ACCEPT
/sbin/iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT
/sbin/iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT

The first commented line is another attempt to make it work.. and this is called in /etc/network/interfaces as a pre-up.

The static route is, gateway, PortA on the cyberoam.

I'm really stuck here, as I said, I can happily get to the device, but nothing else on the lan.

Any ideas??


Additional information... route table from a connected client (mac in this case).

% netstat -rn                                                                                                                                    pnunn@Peters-MacBook-Pro
Routing tables

Destination        Gateway            Flags        Refs      Use   Netif Expire
default          UGSc           68        5     en0
default             UGScI           3        0   utun0
10.8/24             UGSc            1        0   utun0            UHr             7        0   utun0        link#19            UCS             1        0   utun0
127                UCS             1        0     lo0          UH              6  1179613     lo0
169.254            link#4             UCS             1        0     en0
192.168.0          link#4             UCS             4        0     en0     link#4             UCS             2        0     en0        c0:3f:e:e4:c:c     UHLWIir        70      902     en0    375        link#4             UHLWIi          1        7     en0     link#4             UCS             2        0     en0        34:36:3b:cd:ca:20  UHLWIi          1        7     lo0        link#4             UHLWIi          1        0     en0      link#4             UHLWbI          1      894     en0
192.168.1           UGSc            2        5   utun0 link#4             UCS             2        0     en0    link#4             UHLWbI          1       13     en0 link#19            UCSI            1        0   utun0
  • Can you comment this: push "route" line and see. Also see if there is any error log while connecting and post the routing table from a connected client.
    – Diamond
    Feb 24 '16 at 12:46
  • Comment out all the push "route .." lines, connect and see. Those you don't need anyway.
    – Diamond
    Feb 24 '16 at 12:52
  • I removed all of the push "route lines except the one to as without this one my clients don't know how to get to the lan. This made no difference.
    – Peter Nunn
    Feb 24 '16 at 21:11

The VPN client must have route to reach the network, but the machines on the network must also have routes to send back the response.

So you have to instruct the machines on the local network that to reach the vpn client they must send the packet to the raspberry PI IP address (

To confirm that this is the issue, add a route on a network machine : route via

On windows you can add it in a command prompt (as administrator) with

route add MASK

On linux

sudo ip route add via

If this allow this machine to communicate you can add the route on the device acting as gateway for the network.

  • I've added the route back to one of the windows clients, but sadly, no change. I've added the route table to my question (not sure how to put it in a comment).
    – Peter Nunn
    Feb 24 '16 at 21:14
  • Seems it was a combination of the route back and firewall. I installed and configured shorewall and now the machines with the added route are now happy. Thankyou.
    – Peter Nunn
    Feb 24 '16 at 21:56

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.