I am having an enormous difficulty trying to configure a VPN between my house and another location. My router is a Linksys WRT1200AC. A guy on youtube said I needed to install a newer version with kernel 5.x in order to use WireGuard. So I reflashed only to end up bricking the router. Fortunately, I was able to unbrick it and go back to v19. I have v20 on other routers, but apparently its a problem for the WRT1200AC. So this means the client router is v19 and the server is v20 - so no wireguard for me.
So here is my situation, I am switching to a 4G service that blocks all incoming connections. This causes problems for my cameras and asterisk server. So a VPN is pretty much the only thing that will fix this. The cameras do not support VPN so they would have to access it though the router's VPN.
To make things more complicated, I have to have the TV use the 4G with no VPN because streaming is free under my 4G plan. If I streamed through the VPN, I would have to pay extra.
There are instructions online, but they usually say something like, "now upload the ovpn file your commercial VPN service provider gave you" which I don't have. Or they say "fill in the template" but then don't say how to do that.
Lastly, I want it to use a pre shared key with PPTP to keep the overhead down since I don't need any security.
The youtube guy gave some misinformation. I went back and found that wireguard works fine on 19. Or at least I don't get any errors with it. I still don't have it working. I think the problem was that he left out one of the package files that was necessary. I am hesitant because even though the router is easily unbrickable, it still means hours and hours to get the configuration back to the way it was. The save and restore config gui option helps, but doesn't get everything.
So I will be working on this again tomorrow. Its been a solid non-stop week so far and I'm really tired.
PPTP is a much simpler setup and the stuff going in and out is not encrypted now. Thanks for the link to a wireguard setup help. I'll read through those.
Working with Wireguard is really unlikely to cause you to brick your router. But in the event that you do, failsafe mode allows you to boot the router and fix the broken config files.
The backup will save all config files in /etc/config and if you have files that live outside that directory, you can specify additional paths in the /etc/sysupgrade.conf file.
Backups do not retain the user installed packages (config files are backed up, though, per above), but packages are easy to reinstall and there are even some packages that can create a list of user-installed packages and then help automate the re-installation process, too.
This is the equivalent of parking your car in a sketchy neighborhood with valuables on the seat and the doors unlocked. Your network traffic and possibly your entire network could be compromised fairly easily as a result of using PPTP (especially since it is not encrypted). But to each their own, and you have been warned.
21.02.x will work on this device, provided you read the release notes and followed the error message when you try upgrading (DSA migration); using an 21.02 snapshot or master snapshot is recommended to get the mwlwifi bugfix though. As this is a dual-firmware device (which resets back to the alternative after three consecutive failed reboots), so very little danger in trying the current version (19.07.x will be dropped from security support rather soon).
If I remember correctly, the sequence was something like, backup the settings, flash 20, restore the settings = bricked router. This router has a dual image so I was able to get the previous image to come back.
There was a lot missing from the backup file. Like all the hostnames were missing. Even still, there is something flakey about the DNS server that I haven't got right yet. I have a phone ATA that was using the asterisk server name, "raspberryPi", and failed. Yet that name worked with ping. I had to use the direct local IP address to get it working.
I didn't know about all the failsafe modes. That's good to know.
The PPTP is encrypted just as much as TLS1.3, its just that PPTP has no forward security. Meaning that if someone recorded my traffic and then later cracked the key, they could decode all my prior traffic. As I mentioned in the OP, I am going to be using a 4G modem and would have a limited amount of bandwidth. So keeping overhead to a minimum is a must.
Also, since I don't want certain devices to go through the VPN, some type of split tunneling needs to be configured.
Hostnames, if provided to the router as part of the DHCP lease request, will be stored in RAM. This means just power cycling the router will flush those. If the hostnames you are talking about are entered into the dnsmasq setup for DHCP reservations, that should be part of the /etc/config/dhcp file.
Unless I misunderstood your earlier statement, you seemed to indicate that it is not encrypted:
Anyway... for what it is worth [bold emphasis added]:
WireGuard. WireGuard, WireGuard! Seriously, this a really low overhead, very high performance VPN. It uses UDP which helps reduce bandwidth overhead and adds yet another layer of security (the VPN endpoint is not chatty and will not respond to port scans or any other probing -- it only responds to packets containing valid cryptographic keys; and since UDP doesn't require acks, the port that WG is listening on appears to be closed).
I am talking about hostnames under luci->network->hostnames. If those are only stored in RAM then that would explain a few things. However, when I examined the tar,gz dhcp file, it shows two of them under "config domain" - one of which I never actually entered ("LocalWeb"), and the rest are missing. Since openwrt lacks parental controls, these are handy for blocking specific sites by name. ie- Badsite.com -> 127.0.0.1. I'm wondering if saving the config file, then hand adding the sites there, and then restoring would work.
Regarding PPTP, I didn't say that it had no encryption, I said my stuff didn't need encryption since it will be flying wild over the web anyway.
WireGuard seems to be a superior VPN, so I will definitely give it another try. The reason I need a VPN is to open the Tmobile incoming ports, and not for security.
Those installation scripts on your link didn't look all that trivial. The last VPN I set up on a router was just clicking a check box and filling in the credentials, so this is a big jump in complexity.
The reason you need VPN and encryption is that no one except you and VPN server is able to see the traffic and eventually filter it. That is the main purpose of the VPN. I know no ISP provider wanting an extra traffic from outside to the home standard connection. The purpose is to sell extra IP addresses to the customers, moreover to control the bandwidth of the connection. Otherwise a VPS running openvpn plus client on your router can do the job. The VPS will need a public IP address, then you will need to configure site to site connection on openvpn and on top of that you will need to forward certain ports you want to serve from client.
I'm guessing you meant VPN, not VPS. In my case the only reason for the VPN is to get around t-mobiles port blocking. Actually, don't think they are being mean, I think its a technical issue. They are using a NAT shared with thousands of customers, so they can't open a port back to me without a lot of grief. My only hope is a VPN or some other tunneling.
Just about any form of encryption will stop an ISP in their tracks. Its technically illegal to crack someone else's encrypted packets without permission. So if they did crack my weakly encrypted VPN and didn't like what they found, they couldn't do anything about it without risking criminal charges.
That said, if I go with WireGuard, I'll probably be forced to use TLS anyway.
if you have manually entered it, it is likely in the /etc/config/dhcp file
IMO, that's just a naive viewpoint. Encryption is especially important if you are sending stuff over the internet at large. Even if you think your data is not interesting or important -- let's say it was just a little network connected weather station and you're thinking "what harm could there be" if someone was able to access your data...
It's not the ISPs you should be worried about. Not that the law necessarily stops them, but they probably don't care about your traffic. Obviously government surveillance is a topic of concern in many countries, but I'm not even talking about that. The real concern is the people who don't care about the law (or those who are 'untouchable' due to where they live vs where they attack). Bots will crawl the internet and find targets, then the bots and/or actual human attackers will compromise your network and do whatever they please with that access (exfiltrate your data, ransomware attacks, infect your systems with botnet malware, etc).
I meant exactly what I wrote. VPS virtual private server, vpn virtual private network. Encapsulating traffic is one way to get around the problem, but you will also need a node where the traffic enters your system, hence the vps. When you omit encryption, one may easily filter your traffic by examining the packets and filter it by commercially available tools. The node where the traffic enters your system will need public ip address. You may lookup the commercially available services or rent a vps. If you need just one port, a paid service might be an option, if you need more, vps is the way to go. In both options your home router is a vpn client and initiates the connection from your network. This is important, since your network sees the internet, but your network is hidden behind a NAT.
My mistake about the VPS. I haven't made up my mind on the VPN server. I would prefer to use an alternate location that I own so there wont be any extra cost, however, that site has speed limitations that may cause a problem hosting a VPN. It might have issues passing both VOIP and camera video streams at the same time. So I am also considering going with a commercial service which might be the best overall.
In my case, the asterisk server is very lacking in security. It doesn't matter how a hacker gets to it only that he got to it. An ultra-secure VPN isn't going to change anything. I could run sips and srtp, but that still doesn't encrypt the voice stream. Since its just TLS, anyone can connect to it. That is the problem. I just had to manually ban a new hacker this afternoon. The issue with asterisk servers isn't so much that someone can eavesdrop (which could be a problem for some), the problem is hackers continuously hammering the logon trying to brute force their way in. I'm guessing its the same people selling car warranties.
That goes back to overhead which says that I need a server that supports WireGuard. Poor latency is very noticeable with voip.
I didn't get anything done today because I am upgrading my Pi to Buster. Lots of new asterisk pitfalls to have to find workarounds for. Adding WireGuard to the Pi and simply not supporting the cameras is an option if I fail to get OpenWRT to work.
The Asterisk is not any problem when you run it on the top of VPN e.g. openvpn. The problem is nowadays a SIP client for android that provides a video stream. Last good working was Csipsimple which had a video plugin. With GSM codec and H264 video codec you are quite good on a narrow bandwidth. If you need a video chat and have powerful clients, then a Spreed or integrated Nextcloud Talk might be an option. Of course on the top of the vpn. Do not leave the SIP ports open e.g. 5060 port is widely known to attack. If you leave open any authentification channel, install and configure fail2ban service for it. That way you may disencourage malware bots attacking your system.
I switched from 5060 a long time ago, but they seemed to find me again in less than a week. I think they have a sip scanner that checks all ports, and then they tell all their friends. SIP wouldn't really benefit from a VPN unless it was an end to end VPN such as connecting two offices or connecting everybody through a VPN to the office with asterisk. In my case, I have people roaming so I can't even depend on the IP's being fairly consistent.
What I've been seeing is that the hackers themselves have been using VPN's to hack me. That is why Fail2Ban was a good idea that didn't really work. Fail2Ban examines the log files for hack attempts and then adds them to iptables to block their IP. The problem is when they get banned, they just switch to a new terminus at the VPN company and they get a new IP address. Having to search through all those IP addresses slows the system down. Eventually, you get to the point where your legitimate users can't log in from a VPN either.
The problem with asterisk is that it responds to every packet sent to it. That is how they can so easily find your new port.
I have been conceptualizing a system that would examine SIP packets prior to them reaching the asterisk service. Essentially, any packet with incorrect information is intercepted and discarded so asterisk can't respond and give away its presence. This is something that should be built into asterisk but isn't.
Unfortunately, that will have to wait until I get my new asterisk install working properly and configured. I'm going from v11 to v16 and their are a lot of differences in the config files to deal with. Then I still haven't gotten the VPN working.
It is better to use an extetnal sip provider for that purpose, then link in Asterisk local dial node for that. I think Luci has a good configuration interface for that. The v11 and v16 differs so much, that I would better start the configuration from scratch. I think linphone had a free external service, but you might need a paid plan for making video calls.
There are a ton of config files in asterisk, so I have to look at every one of them.
Here is a hypothetical question. If I could get T-mobile to give me a static IPv6 address with all ports open in both directions, would OpenWRT have a mechanism to receive IPv6 packets from the Internet, and then translate them into IPv4 local addresses for IOT devices? And then back again to IPv6?
I am told that asterisk v16 supports IPv6 directly, but I haven't gotten that far yet.