Setting up SNMPD on ReadyNAS Duo v1

The ReadyNas Duo v1 is fairly old now, but is still perfectly capable of providing up to 2TB of shared RAID storage over gigabit ethernet. While it does offer email alerting, I’d prefer to add it to Observium with the rest of my lab, as that’s where the rest of my monitoring is done. Turns out this is actually fairly easy to set up.

1. Power on with new drives and follow reset process.
2. Set up networking and connect to network.
3. Upgrade to latest firmware.
4. Install Toggle SSH patch
5. Install Enable Root SSH patch
6. Install APT patch
7. SSH to NAS ssh root@nas-ip using admin password
8. Install snmpd apt-get install snmpd
9. Configure snmpd.conf

rocommunity <secret>
syslocation Auckland, New Zealand
syscontact Tom Henderson

10. Restart snmpd service /etc/init.d/snmpd restart
11. You should now be able to connect to the NAS over SNMP
12. Finally we need to make sure snmpd starts if the system reboots, by running ln -s ../init.d/snmpd /etc/rc3.d/S99smnp

EdgeRouter L2TP Remote Access VPN

With the release of iOS10 and macOS Sierra, Apple has removed PPTP as a supported VPN connection. Previously I had set up a PPTP VPN for remote access to my home network, so to keep this working I needed to switch to another type of VPN. iOS supports L2TP, IKEv2 and IPSec, and of these the EdgeRouter only supports L2TP as a remote access VPN.

The setup is fairly straightforward, and very similar to the PPTP configuration. The only real difference is the need for a pre-shared secret in the IPSec settings, and firewall rules on WAN_LOCAL to allow IKE, L2TP, ESP and optionally NAT-T.

The EdgeRouter also requires that we define either an outside IP address to listen on, or a DHCP interface to listen on. My pppoe interface has a dynamic IP, but doesn’t use DHCP, so the simplest option seems to be to use 0.0.0.0 as the outside interface. I assume this means that all interfaces are listening, but in practice only the pppoe interface will have the required firewall rules to allow a connection.

I ended up with this config with seems to work perfectly.

Note that my previous configuration had already set set service dns forwarding options "listen-address=10.0.0.1", which is probably also required here.

Azure Automation with Runbooks

Running PowerShell scripts against Azure requires a fair bit of setup - we need a windows computer, Azure PowerShell components, a suitable network to run from etc - and if we need to run them regularly that computer needs to stay online. Fortunately there’s a better way.

By adding an Automation Account to a subscription we can upload scripts (‘runbooks’), and have them run on a schedule, or connect them to a webhook to allow other systems to trigger them by making an http request. There are also tools to integrate with GitHub so your runbooks are stored safely in version control.

Updating a dynamic local gateway IP

I keep a VPN up to extend my home network into Azure. Unfortunately since I don’t have a static IP on my internet connection, this goes down if the IP changes (unfortunately Azure Local Network Gateways require an IP address, not a DNS name). I have a dynamic DNS name pointing at my home IP, so updating this seems like an ideal task for a runbook. All we need to do is resolve my dynamic DNS name, and if it doesn’t match the IP address of the local gateway, update it. Here’s the script:

To get it running in Azure only a few modifications are required.

The Automation Account comes preconfigured with a reasonable set of PowerShell modules, but this script needs AzureRM.Network, which isn’t available by default. It can be added under Assets > Modules > Browse Gallery. We also need to add AzureRM.profile, which is a dependency of AzureRM.Network.

To run this manually we would need to use Login-AzureRMAccount to authenticate with Azure, but since this needs to run non-interactively we need another way. When you create the Automation Account a service principal is added to the directory. You can find it at https://manage.windowsazure.com on the Active Directory tab, in your directory under Applications > Applications my Company Owns.

Back in the Automation Account in the ARM portal, under Assets, we also have two certificates, and two connections for connecting to either the ARM portal or the classic portal using this service principal. To use the connection we just need to add this code to the top of the script:

To add the script we go to the runbooks tab in the Automation Account and create a new PowerShell runbook. Paste the script into the editor, click save, then open the test pane from the toolbar to try out the script (which takes longer to run than it would locally because in the background Azure is creating a fresh VM for it to run from each time). Assuming it runs ok we can publish it, and then create a schedule to run the script.

I now have this running hourly so if my home IP changes the VPN will come back up automatically the next time it runs.

$connectionName = "AzureRunAsConnection"
try {
    $servicePrincipalConnection = Get-AutomationConnection -Name $connectionName         

    Add-AzureRmAccount `
        -ServicePrincipal `
        -TenantId $servicePrincipalConnection.TenantId `
        -ApplicationId $servicePrincipalConnection.ApplicationId `
        -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint 
} catch {
    if (!$servicePrincipalConnection) {
        $ErrorMessage = "Connection $connectionName not found."
        throw $ErrorMessage
    } else {
        Write-Error -Message $_.Exception
        throw $_.Exception
    }
}

$resourceGroup    = 'RG-Network'
$localGatewayName = 'GW-Local'
$hostName = 'host.example.com'
$localGatewayIP   = [system.net.dns]::GetHostByName($hostName).AddressList.IPAddressToString

Write-Output "Checking IP address of $localGatewayName"

$localGateway = Get-AzureRmLocalNetworkGateway -Name $localGatewayName -ResourceGroupName $resourceGroup
$localAddressSpace = $localGateway.AddressSpaceText | ConvertFrom-Json

if ($localGateway.GatewayIpAddress -ne $localGatewayIP) {
    Write-Output "Gateway IP is $($localGateway.GatewayIpAddress), should be $localGatewayIP"
    $localGateway.GatewayIpAddress = $localGatewayIP
    try {
        Set-AzureRmLocalNetworkGateway -LocalNetworkGateway $localGateway -AddressPrefix @($localAddressSpace.AddressPrefixes)
    } catch {
        Write-Error "Failed to change $localGatewayName gateway IP address to $localGatewayIP"
        Write-Error -Message $_.Exception
        throw $_.Exception
    }
} else {
    Write-Output "Gateway IP is correct: $localGatewayIP"
}

Site to Site VPN into Azure with EdgeRouter

These scripts are based on the instructions in the Azure Documentation.

The first step is to set up the Azure side. This script can be run from any machine with the AzureRM PowerShell modules installed. Be sure to read it through and update the variables at the top before you run it.

First we need a resource group to put the Azure objects in, into which we create a new Virtual Network, and create two subnets inside. The first subnet “GatewaySubnet” is important, and must be named exactly that in order to work correctly. The other subnet (“AzureSubnet”) is where we will be attaching our VMs, and can be named anything you like. You can add additional subnets to the Virtual Network later to organise your Azure network.

To represent the local side of the network we create a local network gateway. This is configures with our external IP address, and details of the address space we use internally.

Next we need to request a public IP address, get a reference to our GatewaySubnet, and use these to create a new Virtual Network Gateway IP Config. This is then used to create the Virtual Network Gateway. This step can take up to 20 mins to return a reference to the created object.

The last step is to create a Virtual Network Gateway Connection to link the Virtual Network Gateway with the Local Network Gateway, and configure it to use IPSec and a pre shared key.

With Azure configured, we just need to tell the EdgeRouter to connect. These settings work for me, but may not be optimal. Make sure you set the right interface on line 1. Mine is a pppoe interface, but yours may be different.

To get the public IP address of your new Azure Virtual Network Gateway, you can use:

$remoteGatewayIP = Get-AzureRmPublicIpAddress -Name $remoteGatewayIPAddressName -ResourceGroupName $resourceGroup
Write-Host $remoteGatewayIP.IpAddress

If you need to add additional VPNs - perhaps to a second subscription - set up the Azure side, and create a new site-to-site-peer on the EdgeRouter. You can reuse the same esp-group and ike-group.

After saving the configuration you should be able to see the active connection in the EdgeRouter CLI with show vpn ipsec status, which should return something like:

IPSec Process Running PID: 1703

1 Active IPsec Tunnels

IPsec Interfaces :
        pppoe0  (123.123.123.123)

With the VPN up we can now build Azure VMs in the AzureSubnet of our Virtual Network without creating a public IP for each one.

EdgeRouter PPTP VPN with Dynamic IP Address

Dynamic DNS

Setting up VPN remote access on the EdgeRouter is a pretty straightforward, but without a static IP address we won’t be able to connect back home if the external IP changes. To get around this we can use a dynamic DNS provider like noip.com and have the EdgeRouter update the IP if it changes. After setting up an account and a new dynamic hostname, we can configure the router with:

Configure VPN

Now that we have a DNS name we can set up the PPTP VPN.

First we enable the PPTP VPN using local authentication. This handy because I don’t yet have a RADIUS server to use for authentication. We specify an address pool to hand out to VPN clients, and a DNS server for them to use.

Since I’m using the router as my DNS server I also need to listen for DNS forwarding on that IP, otherwise it won’t respond to DNS requests from the VPN client IP pool.

Finally we need to set up firewall rules that wil allow the PPTP and GRE traffic to reach the router.