1

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
  • Can you comment this: push "route 10.8.0.1 255.255.255.255" line and see. Also see if there is any error log while connecting and post the routing table from a connected client. – Diamant Feb 24 '16 at 12:46
  • Comment out all the push "route .." lines, connect and see. Those you don't need anyway. – Diamant Feb 24 '16 at 12:52
  • I removed all of the push "route lines except the one to 192.168.1.0 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
3

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.

  • 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.