Developing easy-deployed OpenVPN software and Dahua firewall

M

MakeItRain

Pulling my weight
Aug 7, 2017
418
225
Hello Everyone

I have this idea of developing a web-based HTTP GUI (kind of like what routers use) for the Raspberry Pi. It will allow you to easily configure and setup OpenVPN, generate, revoke certificates for any number of users that want to access your home network (through the VPN).

The second functionality of the software (which I am looking into later on) is to act as a gateway(firewall) device for all Dahua NVRs (and cameras). By specifying the gateway IP as the Raspberry Pi on the NVR, essentially, all external Push Notifications, Email alerts, Time NTP server requests, etc. will get intercepted by the Pi. The Pi will parse the request and then forward it out to your main gateway(router) to the internet. This will ensure that only useful, necessary, data is leaving the NVR/camera to the internet and it is not "phoning home" for no reason.

Essentially, one would then be able to set rules in their main router that the NVR and any other IP cam can no longer reach the internet (without the proxy-like authorization from the Raspberry Pi). You may ask, why do this? Well, remember if you block your NVR from reaching the internet, it will not be able to update the NTP, send email alerts or push notifications, and update DNS. Some people may still want this feature without exposing or elevating the security risk.

Lastly, the RPI would be highly secured, accessed via SSH. It will use password-less authentication by way of RSA public/private key pair. This means the ONLY way to break into raspberry pi is having the key. The second security is by having enabled the passphrase for the key. So if you lose the key, the intruder still needs the passphrase(password). The key will be set-up only once. If the key is ever lost, the entire RPI image/software would need to be reloaded.

The idea is to be plug-n-play. Plug it into your home network. It will grab a DHCP address. You can force a static address later. The rest would/should be self-explanatory from the GUI.

So to recap, it will support the following features:

-OpenVPN support (generate, revoke certificates)
-SSH passwordless authentication by SSH key pairs
-Forward email, push alerts, accordingly
-Process NTP requests
-Background DNS updates

The challenge is mostly going to figure out how to intercept the requests coming out of the NVR and them forwarding it accordingly. I think the SDK may have some clues in there for me.

Any thoughts?
 
  • Like
Reactions: smole, mat200 and TL1096r
Thanks. I was looking into pihole and using pivpn. Does this work in conjunction with or totally separate setup?
 
It would work on your current local network, which would be the same subnet as your gateway to the internet. If you have a VLAN setup, then you may have to configure the VLAN such that the NVR on the separate VLAN will be able to talk to the RPI on a different VLAN.
 
I like your idea to use an RPI as "router". But how are you "linking" the two networks (eg the (v)lan to the NVR/cams and the (v)lan to the ISP router). I looked into this, and current RPIs do not use dual nic setups. Or you could use "wifi" to link to your ISP router (with wifi). Or use a USB-NIC and make the linkage there.

Or alternatively look into vlans and vlan tagging and make sure the RPI stack does support the (incoming) tagged traffic. Your downstream managed switch is then able to send the "ISP traffic" to the ISP router/modem.

Hope this helps!
CC
 
alastairstevenson said:
It might be worth a look at the Linux iptables capabilities.
There is a lot of capability, and it's well supported with add-ins.
Click to expand...

Definitely will look into this. I'll check the iptables. Lots of learning curve there for me.. a brief investigation reveals that push notifications are being sent to Apple's APN server at: api.push.apple.com:443 and contains a JSON payload data that looks something like this. Since I am not modifying it, I am just simply parsing/scanning it (maybe looking for specific entries like "Dahua" or "Motion Detection" ...) then I will forward it.

HEADERS
- END_STREAM
+ END_HEADERS
:method = POST
:scheme = https
:path = /3/device/00fc13adff785122b4ad28809a3420982341241421348097878e577c991de8f0
host = api.sandbox.push.apple.com
authorization = bearer eyAia2lkIjogIjhZTDNHM1JSWDciIH0.eyAiaXNzIjogIkM4Nk5WOUpYM0QiLCAiaWF0I
jogIjE0NTkxNDM1ODA2NTAiIH0.MEYCIQDzqyahmH1rz1s-LFNkylXEa2lZ_aOCX4daxxTZkVEGzwIhALvkClnx5m5eAT6
Lxw7LZtEQcH6JENhJTMArwLf3sXwi
apns-id = eabeae54-14a8-11e5-b60b-1697f925ec7b
apns-push-type = alert
apns-expiration = 0
apns-priority = 10
apns-topic = com.example.MyApp
DATA
+ END_STREAM
{ "aps" : { "alert" : "Hello" } }



catcamstar said:
I like your idea to use an RPI as "router". But how are you "linking" the two networks (eg the (v)lan to the NVR/cams and the (v)lan to the ISP router). I looked into this, and current RPIs do not use dual nic setups. Or you could use "wifi" to link to your ISP router (with wifi). Or use a USB-NIC and make the linkage there.

Or alternatively look into vlans and vlan tagging and make sure the RPI stack does support the (incoming) tagged traffic. Your downstream managed switch is then able to send the "ISP traffic" to the ISP router/modem.

Hope this helps!
CC
Click to expand...

What if I use this: It will give me a second eth device at eth1 on the RPI.

usb adapter.jpg
 
My initial conceptual design was that there was no VLAN. The main router gateway is set-up so that the NVR is BLOCKED from all outbound (and inbound [port forwarding]) requests. Push, NTP, email alerts, etc are all denied. Then the RPI acts as a secondary router/firewall (also on the same subnet) as the gateway, RPI, and NVR. The NVR's gateway address becomes the RPI, and not the home router.

Yes, it's possible firmware hacks could go into the NVR and request a new IP allocation from the router and then all the rules in place would be circumvented and also change the gateway IP... so eventually... i will have to use a VLAN anyways.
 
MakeItRain said:
What if I use this: It will give me a second eth device at eth1 on the RPI.

View attachment 43501
Click to expand...

Friend of mine is using something similar, but was not happy with it: do not expect high throughputs (which you might require if watching fullHD streams of the NVR).

Like you write in the post above: it would be a waste of time and energy if you already see that dual NIC might not be the best solution, and go directly for vlan capable.

Now, if you would like to avoid re-inventing the wheel, why not doing it with something that costs the same as a pi, but with full support: Ubiquiti Networks Community -> I've got such an ER-X, can do ... almost all you want! For $50! :-) Does even have a GUI for firewall configuration :p
 
  • Like
Reactions: TL1096r
catcamstar said:
Friend of mine is using something similar, but was not happy with it: do not expect high throughputs (which you might require if watching fullHD streams of the NVR).

Like you write in the post above: it would be a waste of time and energy if you already see that dual NIC might not be the best solution, and go directly for vlan capable.

Now, if you would like to avoid re-inventing the wheel, why not doing it with something that costs the same as a pi, but with full support: Ubiquiti Networks Community -> I've got such an ER-X, can do ... almost all you want! For $50! :) Does even have a GUI for firewall configuration :p
Click to expand...

What does the ER-X do? It gives you the VLAN separation? But it still doesn't intercept/deciper the Dahua outbound notifications and doesn't support SSL-based OpenVPN does it?
 
MakeItRain said:
What does the ER-X do? It gives you the VLAN separation? But it still doesn't intercept/deciper the Dahua outbound notifications and doesn't support SSL-based OpenVPN does it?
Click to expand...

Hold your horses :) Edgerouter-X is ... a full blown linux router, with couple of physical interfaces (gigabit!) which are not present on your Pi. It gives you physical lan tagging, vlan tagging, trunking, openVPN client & server, firewalling, sniffing, DPI, all you can dream on. See: https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_X_DS.pdf. There are larger beasts in that ubiquity family, but to be honest: $50 for a pi as "networking router" or $50 for an ER-X as the real deal, I'd quickly pick my battle :p
 
  • Like
Reactions: mat200 and TL1096r
catcamstar said:
Hold your horses :) Edgerouter-X is ... a full blown linux router, with couple of physical interfaces (gigabit!) which are not present on your Pi. It gives you physical lan tagging, vlan tagging, trunking, openVPN client & server, firewalling, sniffing, DPI, all you can dream on. See: https://dl.ubnt.com/datasheets/edgemax/EdgeRouter_X_DS.pdf. There are larger beasts in that ubiquity family, but to be honest: $50 for a pi as "networking router" or $50 for an ER-X as the real deal, I'd quickly pick my battle :p
Click to expand...

Sweet! Sounds like I need to get my hands on one of these to play with....
 
catcamstar said:
First google hit: EdgeRouter - How to Create a Firewall Rule Using DPI
Click to expand...

Looks like the ERX/USG filters DPI by website/applications and not specifically by the string-matching in the packet (i.e. the payload). So that means, I guess you could say allow the NVR to send data to: "https://api.push.apple.com/" but then you would have no idea what the NVR is sending out.... the assumption is hopefully it is sending out a push notification. Because, what if for example, Dahua or Apple engineer is sending out TCP streams of camera feed to https://api.push.apple.com ... we wouldn't want that...
 
Last edited:
  • Like
Reactions: mat200
MakeItRain said:
Looks like the ERX/USG filters DPI by website/applications and not specifically by the string-matching in the packet (i.e. the payload). So that means, I guess you could say allow the NVR to send data to: "https://api.push.apple.com/" but then you would have no idea what the NVR is sending out.... the assumption is hopefully it is sending out a push notification. Because, what if for example, Dahua or Apple engineer is sending out TCP streams of camera feed to https://api.push.apple.com ... we wouldn't want that...
Click to expand...

Ow indeed, you're right! So I did some digging. Although the ERX does have a proper (user friendly) interface for the firewall, it does use iptables under the hood. In CLI, if you'd run "iptables-save", you can see how the internal translations on the different interfaces (WAN_IN, WAN_OUT etc) occur. So you could potentially work around the iptables (see for example: How can you filter packets by content using native Linux tools such as netfilter?) and drop all "unwanted" content. Or work around a TCPdump solution and three-step log, filter and forward and run such a service on the ERX. For my solar panels, I currently do the log & filter to fetch all "phone home statistics" of the panels with all Volt/temps/amps KPIs. And every month, I pull these logs and import them in my "monitoring dashboard".
 
  • Like
Reactions: TL1096r, mat200 and MakeItRain
@catcamstar @MakeItRain

It would be nice to see a good 2 NIC low cost router / firewall box...


OK, I took a bit of time searching the forum for this one as I recall seeing it posted:

Nice cheap compact computer for low power NAS/NVR

Following the link:

"Overview:

These Industrial ITX machines are based on the same AMD APU SoC as the capable HP T730 thin client. This is a quad core 2.7GHz board with boost clock rates up to 3.6GHz. Typical idle power in Linux with a single SSD, 16GB RAM and a Mellanox Connect-X3 VPI NIC is ~25W. That's around 5W more than the (extremely power efficient) HP T730. Not too shabby for a commodity parts ITX box.

For some context, the T730 thin client is selling for around $160-$200. At $100 or under this is, in my opinion, a very solid purchase.

Why is this machine exciting?
Average power draw before add-in hardware is under 20W at idle running modern Linux
(2) 1Gb NICs: Intel i210 in addition to a Realtek r8168
One full-sized 16x PCIe slot
one mSATA/m-PCIe slot
You can jam at least 6 2.5" drives in the case if you're creative
SATA/mSATA ports aren't shared, you can run 5 drives by default
Runs Proxmox well, and can easily handle two (or more) pfSense VMs without breaking a sweat
Routes gigabit internet like a champ
AES-NI equivalent
AMD IOMMU Support
Under 2U, fits nicely on a shelf
250W Delta FlexATX PSU
 
  • Like
Reactions: catcamstar, TL1096r and alastairstevenson
I forgot to mention that I have been running this PiVPN (OpenVPN) for a while accessing it both at work and overseas) and it has no problem feeding me 8 cameras simultaneously at sub-stream quality on iDMSS. This is done on the Raspberry Pi so there is clearly enough bandwidth and horsepower. For the vast majority of the time, normal users like myself and friends and family will just occasionally log on to VPN on our iPhones, and pull a few live substream feeds and shut-down the app 30 seconds later. We don't ever intend to use it as a full blown (over the WAN) streaming service to monitor our homes remotely at work. The ERX would definitely be a better tool for that job.

The other big advantage of using the Raspberry Pi is that it supports displaycameras script. This utilizes omxplayer which uses the onboard x264 hardware-decoding chip to display nearly 9 camera streams at the same time out of the HDMI port. So the Raspberry Pi can both double as a VPN/router plus the displaycameras setup.

Here's an example of a guy running a setup for his church or something using a set of raspberry pi's and the displaycameras/omxplayer. I have personally tested the displaycameras setup both on wifi and wired and it is quite solid. It runs as a service and even has a cron job set to periodically ensure the feed is okay and restarts any that goes down. Secondly, with spotty wifi interruptions, I've tested it by rebooting my Wi-fi broadcast any cutting my router, the feed will stop and then when the wifi comes back up, the feed immediately re-appears on the RPI's hdmi port.

Currently, I am using LiveCam Pro on iPad 2018 and my sister is using tinyCam PRO app on Android. We run this 24/7 but in my opinion, this method is not reliable. The reason being is because everytime Apple or the app does an update, something breaks. The feed will stop, or Wifi goes down, and the app can't recover the feed. It'll say something stupid like "Check network connection...." and yes, occasionally iOS doesnt' reconnect Wi-Fi. You have to quit the app and go back to iOS main screen, then wi-fi reconnects. I literally have no control. The tablets just look good on the wall, that's it.

At some point, I will switch to buying a cheap monitor/tablet that supports HDMI input and using another Rpi to run the displaycamera on the wall. For my other family members, I got them a RPI3b+ and will use it as a router/VPN and displaycameras to display all 12 cameras on their 70" HDTV.

I am not dismissing the Ubiquiti ERX router at all. It definitely appears to be a quality commercial-grade multi-port router for $60 bucks which is a good deal. But the Raspberry Pi for $35 does have a few tricks up its sleeve and not just a one-trick pony.

Regardless, I think I'm still going to order a edgerouter to play around with. Sometimes, two products can work better as a team together.


large
 
  • Like
Reactions: mat200 and catcamstar
MakeItRain said:
Regardless, I think I'm still going to order a edgerouter to play around with. Sometimes, two products can work better as a team together.
Click to expand...

And I think there lies the answer to many questions: it is not that an ER-X is a 100% replacement of a PI. I also tested out such a pi infrastructure on my television with NVR player capabilities. Although that part went OKish, I ran into another issue: All my networking gear is on UPS, even ISP router. But having that pi on my tele in the living room, hosting VPN, was not an ideal solution. So either I had to add a UPS for tele and pi, or "offload" the VPN capability. That was possible on my ASUS, but having that one in the basement (with tons of metal in the ceiling/floor plus concrete), no wifi signal upstairs. So the ASUS had to go upstairs. But that would again require a UPS to secure the VPN on the ASUS. So my number of networking devices went up with each iteration. To summarize: today only the ASUS is out of the basement (without UPS), but all other components are in the basement, on UPS (being ISP stuff, ER-x (with VPN), managed switch, NVR, NAS, server 1 & 2, domotica, alarm, and some sensor stuff things). Viewing only occurs on tablets/phones, much quicker than "having to look for the remote and switch TV to HDMI2".

All depends on the (security) requirements, network capabilities, physical layout and much more. There is no "one solution fits all", but the ER-X has taken a prominent place in my setup.

Hope this helps!
CC
 
  • Like
Reactions: MakeItRain
So... interesting thing I found out about the Dahua/Amcrest NVR.

So when I push the NVR to use gateway (as the RPI), I can see the NVR try to send a push notify to Apple. But first, it pings for the DNS gateway.push.apple.com to get the IP, which resolves to 17.188.134.26.2195. But here's the kicker, because my Raspberry Pi is not going to redirect at the moment, the NVR doesn't give up. In fact, it goes and traverses the entire subnet hopefully to see if it can get the message out to another gateway. It finds it (my ATT router) and then from that point on, I can no longer capture TCP traffic from the NVR from the RPI. Because now the NVR is layer2-ing with the main router and not the RPI.

So whatever setting you put as the gateway in the NVR, the NVR's firmware will find a way to get the message out. That's why I couldn't understand how was the NVR sending out a PUSH if I set the gateway to the RPI. It must be overriding it...

So what I did next was block the NVR completely from the WAN in the ATT router config. Indeed, what happened next is obvious. The NVR then continues to hammer gateway.push.apple.com via google DNS public (which is what I set). It tries over and over, but because it is talking to the Pi, it fails. The interesting part is, it does not give up! The push notification is buffered and it continues to hammer for Apple's APN DNS address every few seconds...


I'm getting closer. I now know what I need to do. Easiest way is to set up IPtables on the RPI and allow DNS fetch to gateway.push.apple.com and whatever it resolves to. Then only allow packets of a certain size so that it is not maliciously sending video feeds to apple .
 
  • Like
Reactions: mat200, catcamstar and redfive
MakeItRain said:
So whatever setting you put as the gateway in the NVR, the NVR's firmware will find a way to get the message out. That's why I couldn't understand how was the NVR sending out a PUSH if I set the gateway to the RPI. It must be overriding it...
Click to expand...

And that is the reason why I don't like it when people are putting in random gateway ip's or leaving them blank. That's the reason why I advice on vlans. With everything nicely consealed in its own "zone".
 
  • Like
Reactions: TL1096r
You must log in or register to reply here.
Top Bottom