2

So my end goal is to utilise OpenVPN to connect to a remote IP camera. The reason I am going down the route of OpenVPN is to try and overcome the carrier grade NAT that prevents me from doing port forwarding and having a static IP without paying $$$ every month for the privilege.

So below is what the topology looks like, now I can ping devices on Site A LAN (192.168.1.0) from both Site B and C so that's good and proves the VPN is working.

But I cannot ping the IP camera which is situated on Site B (192.168.2.0) from either Site A or from Site B which is my end goal.

I'm still not a 100% sure that my config is correct or if I am missing something.

net.ipv4.ip_forward=1 is enabled on both the OpenVPN server (Debian 8) and the Raspberry Pi.

The other thing I was considering is do I need to set the IP cameras default gateway to be that of the IP of the Raspberry Pi ?

Topology :

enter image description here

Server Config

port 1194
proto udp
dev tun
topology subnet
mode server
tls-server
server 10.8.0.0 255.255.255.0
push "dhcp-option DNS 8.8.8.8"
client-config-dir ccd
client-to-client
route 192.168.2.0 255.255.255.0 10.8.0.3
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/dh2048.pem
keepalive 10 120
comp-lzo
user nobody
group nogroup
daemon
tls-auth /etc/openvpn/easy-rsa/keys/ta.key 0
cipher AES-128-CBC
comp-lzo
persist-key
persist-tun
status /var/log/openvpn-status.log 20
log /var/log/openvpn.log
verb 3

/etc/openvpn/ccd/flexo_client

push "route 192.168.1.0 255.255.255.0 10.8.0.1"
iroute 192.168.2.0 255.255.255.0[/oconf]

client config

client
dev tun
proto udp
remote x.x.x.x 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ns-cert-type server
key-direction 1
cipher AES-128-CBC
comp-lzo
verb 1
mute 20
topology subnet
ca - XML
cert - XML
key -XML
tls-auth - XML

Routing table on OpenVPN server - Site A

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use   Iface
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 eth0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.168.2.0     10.8.0.3        255.255.255.0   UG    0      0        0 tun0

Raspberry Pi routing table - Site B

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use      Iface
0.0.0.0         192.168.2.1     0.0.0.0         UG    303    0        0 wlan0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
192.168.2.0     0.0.0.0         255.255.255.0   U     303    0        0 wlan0

EDIT:

Static routes on router (192.168.1.254) - Site A

Destination     Gateway         Genmask
192.168.2.0     192.168.1.143   255.255.255.0
10.8.0.0        192.168.1.143   255.255.255.0
rda
  • 1,947
  • 1
  • 13
  • 22
Scott
  • 21
  • 3
  • Please also post the routing table from the router on site A. If it is correct what you write and you cannot ping your IP camera on site B from a client on site B, then I suspect you have a connectivity problem not related to the vpn tunnel. Can you ping the Raspberry Pi from a client on site A? – rda Apr 24 '16 at 10:40
  • Did you make any progress? – rda May 20 '16 at 15:00

2 Answers2

0

The other thing I was considering is do I need to set the IP cameras default gateway to be that of the IP of the Raspberry Pi?

YES. Only Raspberry Pi knows where to send traffic targeted to VPN.

Another option is iptables setup with SNAT/MASQUERADE on Raspberry Pi so every connection from VPN network will have source IP set to Raspberry Pi IP.

0

Setting the IP camera's default gateway to the IP of the Raspberry Pi should make it accessible at least from the vpn subnet (as a last resort solution, if you are not able to define routes on your router). As an alternative you could also add the routes from below (site B) to the IP camera, if that is possible.

From a network perspective it is cleaner to add routes to the routing tables of your routers, which will make your whole networks reachable by each other and not only the IP camera.

Just to be sure (it happened to me), check that you do not have any conflicting firewall rules on the Debian server or on the Raspberry Pi.

I have tested your config and it should be working if you add those routes:

Add routes to the router on site B

Destination        Gateway             Genmask
192.168.1.0        192.168.2.254       255.255.255.0
10.8.0.0           192.168.2.254       255.255.255.0     (optional)

The second route is only needed if any other service on the openvpn server machine needs to reach clients on site B or clients on site B need to reach those services via the 10.8.0.1 IP directly.

Add routes to the router on site A

Destination        Gateway             Genmask
192.168.2.0        192.168.1.143       255.255.255.0
10.8.0.0           192.168.1.143       255.255.255.0     (optional)

The second route is only needed if any other service on the Raspberry Pi needs to reach clients on site A or clients on site A need to reach those services via the 10.8.0.3 IP directly.

I was not able to fully test the routes on site A, as my openvpn server runs on the router machine.

Explanantion: When the IP camera (or any other client on site B) gets a packet from the openvpn subnet or from the site A subnet, it does not have a route to those subnets and routes the response to its default gateway (router site B). This gateway (if it knows those routes) routes the packet to next "gateway" (Raspberry Pi).

Push a fixed IP to your Raspberry Pi, by adding the following line to your /etc/openvpn/ccd/flexo_client file (assuming flexo_client is your Pi's certificate CN name):

ifconfig-push 10.8.0.3 255.255.255.0

Otherwise you could loose connectivity in case your Pi gets a different IP address, as your routes would not be correct anymore.

Below are some additional hints to your openvpn config, but they should not have any effect on your problem.

In the server config the directives

mode server
tls-server

are not required, as they are implied by the server 10.8.0.0 255.255.255.0 directive and expand as follows (see manpage):

mode server
tls-server
push "topology subnet"
ifconfig 10.8.0.1 255.255.255.0
ifconfig-pool 10.8.0.2 10.8.0.254 255.255.255.0
push "route-gateway 10.8.0.1"

And also the directive push "dhcp-option DNS 8.8.8.8" should not be required unless you really need it, as the clients connecting to your openvpn server should get their DNS options from their DHCP server. It also only has an effect on windows clients, on non-windows clients it will be saved in an environment variable for optional usage in an up script.

The daemon directive should also not be required (correct me if I am wrong), as it will cause all message and error output to be sent to the syslog facility, which has no effect as the log directive is superseding it. See the manpage for details.

In the client config replace the directive

ns-cert-type server

by

remote-cert-tls server

if possible, as it is a deprecated behavior and not by default enabled by Easy-RSA 3, unless you enable the "Netscape" extensions before signing certs with your CA. See openvpn wiki page

rda
  • 1,947
  • 1
  • 13
  • 22
  • Thank you for taking the time to reply, I seem to of got further whereby I can ping devices on Site B from the OpenVPN server on Site A, however I can not ping devices on Site B from within the LAN on Site A (only from the OpenVPN server). The static route is in place for Site A Destination Gateway Genmask 192.168.2.0 192.168.1.143 255.255.255.0 10.8.0.0 192.168.1.143 255.255.255.0 And I can see the ICMP requests hitting eth0 by tcpdump on the OpenVPN server but the packets go no further, surely they should be forwarded to tun0 ? – Scott Apr 28 '16 at 21:21
  • You are welcome, but in order to help you, I need more specific information. What about the routing table on router on site B (Any static routes created or not possible on the device)? Please be kind and update your question with the routing tables of the two routers and from where (IP) to where (IP) you are able to ping. Try also pinging the Pi on the wlan0 interface (IP -> 192.168.2.254) from a client on site A (IP -> ?), if that works, the routing on site A should be OK. – rda Apr 28 '16 at 22:08