I have a Network Video Recorder which is connected to a raspberry pi directly through ethernet, and the raspberry pi is connected to internet through
wlan0. I want to route all the traffic from the NVR through a VPN connection on the raspberry pi.
Here's how I'm starting the VPN:
openvpn --config /home/pi/my_conf.conf --pull-filter ignore redirect-gateway --route-noexec
I'm ignoring the routes pushed by the server through these commands that I found on the open VPN tutorials. Upon inspection, I see that a
tun0 device is created after I connect to my VPN.
So in order to route the traffic from the NVR to the VPN, I need to give the
eth0 interface of the raspberry pi a static IP in the range used by the NVR. I did it by the following in
interface eth0 static ip_address=192.168.1.1/24 static routers=192.168.1.1 static domain_name_servers=192.168.1.1
wlan0 has the gateway
192.168.0.1 so there's no conflict. Now that I have an IP address for the eth interface which is in the range of the NVR, and I have a connection to the VPN server on the
tun0, all I need to do is to add a route to
tun0 for the IP addresses the NVR is going to access. Since I want to access some IP cameras in the range 192.168.0/24, here's what I did to my routing table:
pi@raspberrypi:~ $ route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 0.0.0.0 192.168.1.1 0.0.0.0 UG 202 0 0 eth0 0.0.0.0 192.168.0.1 0.0.0.0 UG 304 0 0 wlan0 192.168.0.0 0.0.0.0 255.255.255.0 U 304 0 0 wlan0 192.168.1.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 202 0 0 eth0 192.168.255.5 0.0.0.0 255.255.255.255 UH 0 0 0 tun0
you can see that everything in the range
192.168.1.0/24 goes through
tun0 because it has metric
Even though I'm also running
eth0, I'm using a static IP address on the NVR too, which is
Obviously I can't access any cameras in the NVR. I tried to add connection on the NVR to the
192.168.1.189 camera. I tried to run
eth0, this is mainly what I see:
17:10:46.673062 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.1.189 tell 192.168.1.9, length 46
The NVR (
192.168.1.9) is trying to find out who is
192.168.1.189, but there's no response. Nothing is being routed, I guess. I also tried to ping
192.168.1.189 on raspberry pi just to see if it worked. It worked the first time I tried. After some minutes, I can't ping it anymore, I don't know why. Pinging
192.168.1.1 always works though.
I kinda understood the problem I'm having. Since the NVR is on the
192.168.1.0/24 subnet and is trying to access a camera on the same subnet, its IP packets are not sent to the gateway (raspberry pi). It instead tries to find where is
192.168.1.189 (the camera) by sending ARP requests as I was seeing in the tcpdump.
In order to solve this problem I changed the subnet of the NVR to
192.168.2.0/24 and gave the address
192.168.2.1 to the
eth0 interface of the raspberry pi. I now can see every packet sent by the NVR to the cameras and to some amazon servers and so. However, there is no response. The NVR only sends packets but receives nothing. I've checked and the routes to
tun0 are ok so the packets should go through it. However packets are not returning.
instead of manually adding routes, I added the following to my open vpn configuration file in the client:
route 192.168.1.0 255.255.255.0 route-metric 0 route-nopull
client. I can now see this route on the routing table after I connect my VPN. I can also ping to it from the raspberry pi and it works. However it looks like the NVR still only sends packets, and receives nothing
Important: If I run
tcpdump -vvv -i eth0 I see a lot of packets destined to
192.168.1.189 which is my camera. They should go to
tun0 because there's a route with metric
0 that makes them go through it. If I run
tcpdump -vvv -i tun0 I see nothing, even if I let it for minutes. So things are not being routed through there. If, however, I run
ping 192.168.1.189 inside my raspberry pi (through ssh) I can see all the ping packets in tcpdump of
tun0, which confirms that the route works. It isn't working for the packets coming from ethernet though.