A couple of years ago I wrote a post about a dual ISP config with a Juniper SRX firewall. At the time I ran into some challenges regarding the DHCP client functionality of the SRX. For some reason it couldn't get a lease from the Ziggo ISP DHCP servers. Any other DHCP server on my local network worked just fine. Since I created a work-around at the time (by using an additional NAT router and static IP addresses) I didn't give it much thought.... Until last week.
Last week I ran into a networking challenge that kinda freaked me out. For some reason my Apple TV wouldn't connect to my NAS, but it could connect to the Internet. For some reason my Apple TV got a public IP address while it was located on my internal network. The public IP address was completely unknown to me. So, WTF was giving my Apple TV a public IP address?
NGINX (pronounced as engine-x) is a versatile (reverse) proxy service for Linux which can be used for many purposes. This post gives a relative small and easy example that I use at home for accessing insecure web services in my home. These are:
- Domoticz
Free and opensource Domotica software - SabNZBd
Free and opensource software for downloading binaries from usenet. Available for multiple operating systems - Sonarr
(former NZBDrone) is a so-called PVR (personal video recorder) for Usenet users, which checks multiple RSS feeds (also called Indexer) for new episodes of the shows you're following.
These services run on different platforms and are not protected by username/password or encryption. Something that's not done if you want to access this over the Internet.
To get secure access to these services you might want to use a VPN solution into your home, but you can also achieve this by using a reverse proxy that 'protects' these services.
I run my NGINX reverse proxy on Ubuntu Linux, but it will also run on the average Raspberry Pi.
We have a lab which we can access by using a VPN (Cisco ASA and Cisco AnyConnect). This setup has a so-called split DNS configuration, which means that only resources in the lab are accessed through the VPN tunnel. Regular Internet traffic uses my local DSL connection.
At my house I (like most folks) rely on DHCP for providing me with IP address, gateway and DNS servers. My local subnet uses 192.168.10.1 for DNS and 192.168.10.254 is my default gateway. So my clients are in the same subnet as my DNS server (directly-connected).
All these things considered I should be able to browse the Internet while I have a VPN running. Well, that's where you're wrong.
This post is about something that bothers me a lot. Especially, because it originates from a place where you think they should know better. It's about Dots-Per-Inch (DPI) and JPEG (the popular digital image/photo format).
It all starts, when I read the requirements of certain online photo contests. The criteria for entering the contest contain the following: The photo entering the contest must be in JPEG with maximum quality (least compression), AND 300 DPI.
This weekend went my Internet (VDLS) down. The DSL part was still up, but the IPv4 connectivity (over PPPoE) was down. When I checked the Fritzbox (7340) I saw that the DLS had 'trained' on ~100Mbps down and ~30Mbps up. Connection speeds I could only dream of......
Trying to re-establish the IPv4 connection I restarted the DSL modem. Upon reboot, it trained on about 70Mbps download and 30Mbps upload, and the PPPoE tunnel for IPv4 established nicely..... for about 5 minutes.
It turned out that the DSL connection tried to get a better connection, and got it. So starting off at 70Mbps, it could establish a 74Mbps a couple of seconds later, and 75Mbps a bit later after that, and so on, and so on. During this time the PPPoE connection worked like a charm. Until the DSL reached the magical 100Mbps rate. That's when the PPPoE (and the actual IPv4 connection to the Internet) failed.
The Juniper Virtual SRX firewall can run on multiple platforms, but VMware Workstation is not mentioned in the list of supported platforms. Having some experience with both, I know that almost all VM's designed for the VMware ESXi environment will run on the (stand-alone) VMware Workstation product.
I downloaded the .ova file from the Juniper website and imported it in VMware Workstation v12.1. During the import I adjusted the number of CPU's to save resources, which turned out to be a mistake. The VM really needs the two CPU's, because if you don't it just won't work (routing failures, etc..). So, don't change the defaults for CPU and memory.