problems when openvpn server is not the default gateway

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.

server...

local 192.168.1.84
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 10.8.0.0 255.255.255.0  # internal tun0 connection IP
ifconfig 10.8.0.1 10.8.0.2
ifconfig-pool-persist ipp.txt
push "route 10.8.0.1 255.255.255.255"
#route 192.168.1.0 255.255.255.0
push "route 10.8.0.0 255.255.255.0"
push "route 192.168.1.0 255.255.255.0"
#push dhcp-option DNS 8.8.8.8"
push "redirect-gateway def1"
keepalive 30 240

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

status log/openvpn-status.log

verb 3  # verbose mode
client-to-client
duplicate-cn

client config to match, nothing much in it..

firewall.sh

#!/bin/bash

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


/sbin/iptables -A INPUT -i tun+ -j ACCEPT
/sbin/iptables -A OUTPUT -o tun+ -j ACCEPT
/sbin/iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
/sbin/iptables -I FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -d 192.168.1.0/24 -m conntrack --ctstate NEW -j ACCEPT
/sbin/iptables -I FORWARD -i tun0 -o eth0 -s 10.8.0.0/24 -d 10.1.0.0/8 -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 10.8.0.0/24, gateway 192.168.1.84, PortA on the cyberoam.

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

Any ideas??

Peter.

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

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

Internet:
Destination        Gateway            Flags        Refs      Use   Netif Expire
default            192.168.0.1        UGSc           68        5     en0
default            10.8.0.5           UGScI           3        0   utun0
10.8/24            10.8.0.5           UGSc            1        0   utun0
10.8.0.5           10.8.0.6           UHr             7        0   utun0
10.8.0.5/32        link#19            UCS             1        0   utun0
127                127.0.0.1          UCS             1        0     lo0
127.0.0.1          127.0.0.1          UH              6  1179613     lo0
169.254            link#4             UCS             1        0     en0
192.168.0          link#4             UCS             4        0     en0
192.168.0.1/32     link#4             UCS             2        0     en0
192.168.0.1        c0:3f:e:e4:c:c     UHLWIir        70      902     en0    375
192.168.0.4        link#4             UHLWIi          1        7     en0
192.168.0.5/32     link#4             UCS             2        0     en0
192.168.0.5        34:36:3b:cd:ca:20  UHLWIi          1        7     lo0
192.168.0.6        link#4             UHLWIi          1        0     en0
192.168.0.255      link#4             UHLWbI          1      894     en0
192.168.1          10.8.0.5           UGSc            2        5   utun0
255.255.255.255/32 link#4             UCS             2        0     en0
255.255.255.255    link#4             UHLWbI          1       13     en0

255.255.255.255/32 link#19            UCSI            1        0   utun0

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 (192.168.1.84)

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

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

route add 10.8.0.0 MASK 255.255.255.0 192.168.1.84

On linux

sudo ip route add 10.8.0.0/24 via 192.168.1.84

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