Setting up the RPiGateway into my HomeLab

So now that I have a better handle on how the wifi works at GSV, I want to provide myself a way into the HomeLab through a portal.  I have a Raspberry Pi, RPiGateway, that is connected to the GSV portal wifi network that I can get to from my iPad.  I have the luxury of being able to get out that Raspberry Pi from anywhere on campus using my iPad through the wifi network. I want to be able to get to applications, update my HomeLab services, change things within my HomeLab, and do other types of things remotely.  I can do this by setting up the RPiGateway for access.  I will need to control access to the RPiGateway to ensure that only known entities should be able to access the information.  That means that my personal laptop or any iPhone/iPad device that I own should be able to get into the network.  Access control can be done via encryption and known certificates.  So the following items may need to be considered:

• Use certificates validated through Lets Encrypt and their process of 90 days
• Use synchronous certificates that are self certified including a local CA
• Provide both SSH and VPN access into the HomeLab through RPiGateway
• SSH should rely on the synchronous certificates
• VPN should rely on the Lets Encrypt certificates
• I have the following protocols that need to be addressed over each HomeLab service: RDP, HTTP/HTTPS, SSH
• May have to include some NGINX and Apache Guacamole interfaces to equipment
• Might need to decide if this is a service through the Proxmox server, or on the RPiGateway
• Security might need to be offloaded from RPiGateway
• What needs to be done to the HomeLab side of RPiGateway to decrease risk if RPiGateway is compromised

All of these elements need to be considered.  Right now I can start setting things up that are accessible via the SSH port on RPiGateway, even though this would mean some special Apps on the iPhone/iPad.

Update: it turns out that getting a Lets Encrypt cert is a pain if you don’t have internet access to your web server.  This is not my case, so I will have to rely on a local CA to do certificates.  I am also realizing that I may want to move RPiGateway further into the HomeLab in the future, so I need to adjust for that.

History - The Current Setup of the GSV HomeLab

Environment - I live in an apartment in a wifi only environment.  There are two SSIDs for the tenants which allow connection of most devices. One SSID is open but is MAC address enabled based on a list, the other is encrypted and requires authentication.  The two wifi services are keyed to the resident accounts so that communication can happen between them for a single resident; but not to other resident computers using the same network topology.  The biggest problem for me having a HomeLab is to be able to do things in this environment.  In addition, the construction of the apartments are done with a view to fire safety, not to the transmission of wifi signals.  I experience a drop of almost 30 dBm from the living room to the back bedroom in signal level.  But, my HomeLab equipment is in the back bedroom and the wifi end point is in the living room, hence my dilemma.

Desires - Within the HomeLab, I have things that I want to accomplish in the living room, as well as the back bedroom.  In addition, I need the opportunity to move around the apartment at will and still do things on my HomeLab vlans.  I have no need to leave the apartment on a regular basis since I am retired.  So having a VPN connecting into my HomeLab is not necessary, unless I go on a trip.  I have no control over the wifi environment, nor can I tunnel through walls to pull Ethernet cable.  So, my HomeLab setup has to be coordinated with the circumstances.

Setup - I have to have a way into my HomeLab which is connected to the wifi environment.  I do this through a GL-iNet SLATE router which acts as a wifi bridge to my rack of equipment.  Early on I had the SLATE on top of the rack of equipment connected into the wifi environment on the encrypted side and the LAN of the SLATE plugged into the WAN port of my Ubiquiti Edgerouter-12 (ER-12).  However, I discovered that the signal level was about -78 dBm with a noise floor of around -71 dBm.  So my signal was below the noise floor; not a good situation if you want to get maximum speed.  What I then decided to do was put the SLATE in the living room, with a connection through a couple of Powerline adapters to the back bedroom where my rack of equipment resided.  That worked very well since I was getting essentially the maximum level of wifi signal that I could get in the environment.  But, as I started getting my HomeLab organized, it was apparent that I needed to get some additional equipment into the living room.  

I decided to change out the single channel through the Powerline adapters into a trunk line between two managed switches.  I placed a Netgear GS108Tv2 switch in the living room with a port configured as a trunk line with all of my defined vlans (13 in all).  That was plugged into the living room Powerline adapter and in the back bedroom the Powerline adapter was plugged into a port on a Netgear M4100-26g switch port configured with the same trunk line.  The untagged vlan on each trunk port was a dummy that only exists between the two switches.  I then configured an untagged vlan port on the two switches that would be used to pass Ethernet signals in the direction of SLATE to ER-12.  I plugged the SLATE into the resultant unmanaged port on the GS108Tv2.  The other resultant unmanaged port on the M4100-26g was then plugged into the WAN port of my ER-12.  I placed a Raspberry Pi in the living room and plugged it into a different untagged port on the GS108Tv2 which led back to the M4100-26g via the trunk to other things I was doing.  This setup now allows me to bring other equipment into the living room and place them on different vlans as I see fit.

An additional need was presented when I discovered that my Sleep Number bed needed connection to the internet but would only work with a WPA/WPA2 enabled wifi setup.  Neither of the two wifi SSIDs allowed this capability. I had to add an additional router, a D-Link DIR-505L, setup as a wifi repeater connected into the open SSID on the WAN side and presenting a WPA/WPA2 wifi signal on the LAN side.  I was then able to connect my Sleep Number bed once I added it to the small bedroom near the bed itself.  Since the DIR-505L is a wall-wart it was easily concealed under a vanity.  The WPA/WPA2 signal was also used by my Tempest Weather Station hub for connection to the internet.  In addition, I have a Raspberry Pi which is connected into the WPA/WPA2 signal and also to one of the vlans in my HomeLab rack.

I had brought a couple of my wifi access ports with me to the retirement apartment.  I set one of them up with 4 SSIDs (two disabled for now), one of them for use with my personal laptop to connect within my HomeLab and the other connected into the vlan used for controlling my Tasmota switches.  The Tasmota switches are currently used to turn on/off equipment in the HomeLab rack remotely.

Thus the saga of my changes to my HomeLab as a result of the wifi environment ends.

Using an RTL-SDR usb dongle to get other weather stations signals

I was futzing around last night repurposing some Raspberry Pis (bought before they were $180 apiece due to chip shortage) in my network rack. I took one of the RPis and installed RTL_433, node red, and plugged an RTL-SDR dongle into it along with a small antenna. I am going to use node red to push data to an MQTT service for use with my weather data extraction setup. I mostly wanted to see if I could pick up an Accurite Temperature sensor (606TX) on my balcony at 433.925 MHz. What I wasn’t expecting was picking up a couple other temperature sensors, one Accurite and one Oregon Scientific models.

I live in a retirement community and for the most part the residents are not really that tech-savvy, or computer-savvy for that matter. So I wouldn’t expect them to have a lot of weather station gear. My 606TX only gives back temperature on the balcony, but I noticed that it was reading a temperature about 2 degrees C higher than the Oregon Scientific model. The Oregon Scientific model also gave back humidity. I am thinking of gathering data from each of the other models to extract trends. My balcony faces north and that might be the cause of the temperature difference in the summer time.

I haven’t played with the gain of the dongle or looked into other frequencies yet. I am pretty sure that my Tempest, also on my balcony, transmits on the 915 MHz band, but I have not been able to capture it’s data set yet with the dongle.

Alteration to the Network Input to/from the Rack

 I have been contemplating how to provide an interface into the rack that would allow me to provide an interface to the RPis and the Proxmox server on the rack.  So far I have had an interface to the Edgerouter-12 (ER-12) through a SLATE router.  However, I found out that the rule set that is being used here in the retirement community doesn’t allow me to access ports on the SLATE unless I am connected to their portal vlan.  I decided to start some experiments to find out what I can actually do with the network.  Be aware that all IP addresses within the retirement community are RFC1918 private addresses.

I had previously connected the SLATE router to the ER-12 through two AV2000 Ethernet over power interfaces, each with two Ethernet ports apiece.  So it was SLATE LAN -> AV2000 -> AV2000 -> ER-12 WAN.  The SLATE was connected into the resident vlan which does not allow conversation between hosts on the resident vlan.  However, I have been able to connect between a host on the resident vlan and a host on the portal vlan.  I decided to put an RPi connected to the portal vlan, but also connected to a vlan within the rack.  That way, I can connect my laptop, or iPhone/iPad to any port on the RPi.  To do this, I decided to implement a trunk line between the two AV2000s.

I resurrected one of the managed switches from the tubs that I brought to the community and configured a trunk port and an untagged port to a vlan (vlan32) specifically for traffic between the SLATE and the ER-12.  I configured the same vlan (vlan32) on my M4100-26G switch along with a trunk port that had the same setup as the trunk port on the managed switch from my tub stores.  By connecting these up I now have the following:  SLATE LAN (vlan32) -> managed switch -[T]-> AV2000 -> AV2000 -[T]-> M4100-26G -[vlan32]-> ER-12 WAN (vlan32).

Since I can get to the managed switch within the rack from the Admin vlan, I was able to set other vlans so that I can add an RPi Gateway (ServerNet vlan/portal vlan).  This allows me to setup a firewall with open ports to the ServerNet vlan from the portal vlan which is wifi facing.  Next up is the configuration of the RPi Gateway.

WWD #03 - Setting up data_gather for Tempest weather station

 I have been extracting information from my Tempest weather station (TWS) via the WeatherFlow Tempest REST api.  It involves signing up for a key from their website for your particular TWS, then sending a crafted URI with the key, and sometimes your weather station id.  There is a limitation on the number of samples you can get over time unless you sign up for a business account, but at least you can get to your own data.

To sign up for the key you log into your account at TempestWx.com.  Then select the Settings icon on the upper right hand side.  That brings up a Settings page.  Go to the bottom, there you will find a link, "Data Authorizations".  When you select that you will see a create Token button on the top right corner.  Selecting that button will create a token key that can be used with the Tempest api to get information that was sent to TempestWx.com from your TWS.

You use the token as follows:  assume that my token is 12345678-1234-1234-1234-123456789098.  You can get the station information, which comes back in a JSON format by using the URI, https://swd.weatherflow.com/swd/rest/stations?token=12345678-1234-1234-1234-123456789098.  This will send back a JSON message similar to the following (showing a station_id of 12345 from stations[0].station_id) - 

{

  "stations": [
    {
      "location_id": 12345,
      "station_id": 12345,
      "name": "My TWS Name",
      "public_name": "My TWS Name",
      "latitude": 99.99999,
      "longitude": -99.99999,
      "timezone": "America/New_York",
      "timezone_offset_minutes": -240,
      "station_meta": {
        "share_with_wf": true,
        "share_with_wu": true,
        "elevation": 78.30184936523438
      },
      "last_modified_epoch": 1656712447,
      "created_epoch": 1630250472,
      "devices": [ ...

To get a sample, probably once every 1.0 minutes max, you would use a URI, https://swd.weatherflow.com/swd/rest/observations/station/12345?token=12345678-1234-1234-1234-123456789098. This will send back a JSON message similar to the one above, with the latest observation from your TWS under obs[0].

I will be prototyping this using an http request node within the data_gather container written in node-red.  I am going to push this to the MQTT server as a /weather/TWS/observation topic.  I am however going to reduce the number of items sent.