Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Bill Meeks]

Is this a realistic way to do this same thing but without requiring port forwarding at the remote end?
https://jordancrawford.kiwi/home-server-without-portforward/

The OpenVPN application I provided as an example uses UDP over port 1194.

The application described in the link Andrew provided is really, when you dispense with all the fancy jargon, just another version of TeamViewer or LogMeIn in terms of how traffic flows. Something in your home network (a Plex Server or that RPI box, for instance) is maintaining a constant connection to a third-party server in the cloud. That cloud connection then listens for other incoming remote connections and can then route them to your home network via that contantly-open connection I mentioned. That's why no port forwarding is required. Something on the inside is always in constant communication with that outside cloud server. There is nothing wrong with this method, but it can be much more difficult to set up than say a TeamViewer or LogMeIn session would be. This is especially true for one-off or short-term requirements.

Done improperly, port forwarding can indeed present a huge security hole in a network. It requires having expertise in networking security to properly set things up with a capable firewall. Vanilla port-forwarding as is done with most consumer routers (think Netgear, LinkSys, Asus, etc.) can expose the internal network to quite large security vulnerabilities. In fact I would go so far as to say it should never be done. When you use a product like OpenVPN with a capable firewall (like pfSense, as an example), the initial connection from the remote client back into the firewall and VPN tunnel is authentiated using a public/private key certificate. That is, for all practical purposes, an un-guessable extremely long password. So nothing passes over the port forward until it is authenticated by the certificate key. That's way different than what you get with a typical consumer router when you just tell it to forward anything for port X to some internal IP. At that point you had better make darn sure the internal host is secure! It can be done, but it takes vigilance.

For my home network I have a firewall configured with OpenVPN. I have my own domain name that I've owned for years. I use a dynamic DNS client on my firewall to register my firewall's public IP address with my domain hosting provider's DNS infrastructure. Thus I can always connect to my home network firewall from anywhere in the world using my domain name just as you can connect to www.cnn.com from anywhere in the world. I created an OpenVPN install client for my iPhone and iPad using the OpenVPN tools. I installed the client on my iOS devices (by emailing it to myself as an attachment). Now I can simply open a VPN session on my iPhone or iPad, open an RDP (remote desktop protocol) app I installed on them and log into any PC on my home network. This connection is highly secure as it is encrypted over the VPN tunnel, and all authentication is via a certificate key. Over the VPN, I in effect have a LAN cable to my iOS devices anywhere in the world I may be. I prefer this setup to the third-party listening client I described earlier because I have more control over what comes and goes in my network.

[Bill Meeks]

Forgive my ignorance and dumb questions - I'm a bit of a networking newb. (But trying to learn!)

From what I've read, this can be done with "port forwarding" (without VPN) but that this would be a very bad idea as it creates a huge security hole in your network that anyone can gain access to. (and probably why nobody's mentioning it here). True?
From what I've further read, port forwarding + VPN is one way to go, as you gentlemen are discussing.

One issue you are likely to hit with port forwarding is finding out exactly how the Yamaha software connects to the console. I have Studio Manager (for an LS9) and TF Editor for a TF5. Both have a box for you to enter the IP address of the console, but I suspect if you put a port number on the end of the IP address the editor software will balk. For port forwards to work, you have to know what the incoming port number will be that you want forwarded to a specific host. I suspect that you can't choose your own by tacking it onto the IP address when you configured the Yamaha tools. So that leaves you the task of sniffing the network with Wireshark as a normal connection is made between the Yamaha software and a console, and then examining the trace to discover the port number. And it very well may be each editor uses a different port to connect to. Note that what I really am talking about here is that you need to find out what "port" the Yamaha console is listening on for incoming IP connections from the editor software. That's the port you would then configure forwarding for in your firewall or consumer router.

[Scott Holtzman]

Is this a realistic way to do this same thing but without requiring port forwarding at the remote end?
https://jordancrawford.kiwi/home-server-without-portforward/

That made my head hurt and networking is my top core competence. 


I am going to take care of setting up the VPN for Brian ,he needs a real point to point.  Not an app.


BTW OpenVPN is so yesterday.   Wireguard is the future of Open Source VPN's.  It's in both the Debian and Red Hat kernels.


With that being said I am going to use a Microtik router to run OpenVPN for him as they are economical and will generate a 10 year x509 key.

[Bill Meeks]

BTW OpenVPN is so yesterday.   Wireguard is the future of Open Source VPN's.  It's in both the Debian and Red Hat kernels.


With that being said I am going to use a Microtik router to run OpenVPN for him as they are economical and will generate a 10 year x509 key.

Yeah, so far as I know Wireguard is still in userland for FreeBSD. Netgate, the pfSense sponsor I mentioned, is also sponsoring work to move Wireguard into the FreeBSD kernel. For now, while still slow, OpenVPN outperforms Wireguard in FreeBSD. That will change when Wireguard goes kernel-mode.

[Russell Ault]

[...] BTW OpenVPN is so yesterday.   Wireguard is the future of Open Source VPN's.  It's in both the Debian and Red Hat kernels. [...]

...and this is why I read everything network-related on these forums. Wireguard had passed totally under my radar until now. Thanks, Scott!

Yeah, so far as I know Wireguard is still in userland for FreeBSD. Netgate, the pfSense sponsor I mentioned, is also sponsoring work to move Wireguard into the FreeBSD kernel. For now, while still slow, OpenVPN outperforms Wireguard in FreeBSD. That will change when Wireguard goes kernel-mode.

As of about a week ago it's been merged into the OpenBSD CVS, so I'm guessing it won't be too much longer for FreeBSD.

-Russ

[Andrew Broughton]

One issue you are likely to hit with port forwarding is finding out exactly how the Yamaha software connects to the console. I have Studio Manager (for an LS9) and TF Editor for a TF5. Both have a box for you to enter the IP address of the console, but I suspect if you put a port number on the end of the IP address the editor software will balk. For port forwards to work, you have to know what the incoming port number will be that you want forwarded to a specific host. I suspect that you can't choose your own by tacking it onto the IP address when you configured the Yamaha tools. So that leaves you the task of sniffing the network with Wireshark as a normal connection is made between the Yamaha software and a console, and then examining the trace to discover the port number. And it very well may be each editor uses a different port to connect to. Note that what I really am talking about here is that you need to find out what "port" the Yamaha console is listening on for incoming IP connections from the editor software. That's the port you would then configure forwarding for in your firewall or consumer router.

Been all over that for years. Click on my sig if you're curious.
Thanks for the advice on the VPN stuff!

[Andrew Broughton]

That made my head hurt and networking is my top core competence. 


I am going to take care of setting up the VPN for Brian ,he needs a real point to point.  Not an app.


BTW OpenVPN is so yesterday.   Wireguard is the future of Open Source VPN's.  It's in both the Debian and Red Hat kernels.


With that being said I am going to use a Microtik router to run OpenVPN for him as they are economical and will generate a 10 year x509 key.

Awesome. Thank you, Scott! I'm working with Brian on this project, so I'm excited to see what you have in store for him.


I also want to know more about how this is done, particularly using DIY methods (but not for this project), if that's possible.

[Scott Holtzman]

Yeah, so far as I know Wireguard is still in userland for FreeBSD. Netgate, the pfSense sponsor I mentioned, is also sponsoring work to move Wireguard into the FreeBSD kernel. For now, while still slow, OpenVPN outperforms Wireguard in FreeBSD. That will change when Wireguard goes kernel-mode.

I like pfSense and recommend it, I have heard that a major rewrite is either in progress or moved to a testing branch.  I did however go over to the dark side and convert our Ubiquity network with a host of open source thread detection and response tools to a Fortinet solution for better BGP support, centralized config, update and backup management and better threat assessment libraries. 


Only thing I do on FreeBSD is ZFS NAS boxes for virtual machine storage.

[Bill Meeks]

I like pfSense and recommend it, I have heard that a major rewrite is either in progress or moved to a testing branch.  I did however go over to the dark side and convert our Ubiquity network with a host of open source thread detection and response tools to a Fortinet solution for better BGP support, centralized config, update and backup management and better threat assessment libraries. 


Only thing I do on FreeBSD is ZFS NAS boxes for virtual machine storage.

The current RELEASE version of pfSense (2.4.5_p1) is based on FreeBSD-11.3/STABLE. The DEVEL version (2.5) is based on FreeBSD-12.1/STABLE. The GUI is PHP with Bootstrap HTML for now.

I have used pfSense privately for years. In my professional vocation I managed Checkpoint firewalls for years. Right as I was retiring my employer made a switch to Palo Alto for most firewalls although there were still some Checkpoints around. I created and now maintain the Suricata package for pfSense, and I took over maintenance of the Snort package on pfSense several years ago.

[Scott Holtzman]

The current RELEASE version of pfSense (2.4.5_p1) is based on FreeBSD-11.3/STABLE. The DEVEL version (2.5) is based on FreeBSD-12.1/STABLE. The GUI is PHP with Bootstrap HTML for now.

I have used pfSense privately for years. In my professional vocation I managed Checkpoint firewalls for years. Right as I was retiring my employer made a switch to Palo Alto for most firewalls although there were still some Checkpoints around. I created and now maintain the Suricata package for pfSense, and I took over maintenance of the Snort package on pfSense several years ago.

Very cool, I am one of the founders of the FreePBX project, an open source PBX that utilizes Asterisk for call handling.  We also produce a turnkey distro using our own version of Red Hat.  I am currently the Director of Engineering for Sangoma Technologies.  Sangoma acquired the FreePBX project, my FreePBX hosting company, Dialogic and Digium, the developers of Asterisk in the last 5 years.  Currently my most interesting project is automated provision of hybrid cloud infrastructure using Ansible and Terraform.   Sangoma's culture is Open Source fanatics and the biggest culture clash is the Docker vs. Kubernetes crowd.  We should chat someday have you looked at OpenVAS?

[ProSoundWeb Community]