the vimoire

recent

See 121 more →

Running local Monero node behind a VPN with Wireguard and OPNsense

5 min read

I’ve wanted to set up a VPN for running my XMR node since day one, but I haven’t wanted to set one up unless I could pay for it with XMR. I finally have accrued enough to pay for a year and thus I did.

Here is how I set it up on OPNsense. I followed this guide mostly, with some adaptations as necessary (as I did not plan to run it LAN-wide, just on the MINE interface.)

Refer to some of my other posts for my VLAN setup. I used the guide but replaced any instances of the LAN interface with the MINE interface. I will let the guide do most of the heavy lifting (here is an archive link)

Configurations

Generate configuration

This is done on the VPN website and differs per each service. The point is you want to get a WireGuard configuration file with all the keys in it to use for the next steps.

Set up IPv6 configuration

I had to:

  • Disable IPv6 on WAN (I don’t use it anyway)
  • Enable IPv6 on MINE interface
  • Enable IPv6 DHCP (now marked as legacy on OPNsense but still supported)
    • Enable, then set range from ::1000 to ::2000
  • Enable router advertisements on MINE and set to Managed (GUI has changed a lot since the guide, defaults should suffice)

Test to ensure clients are receiving IPv6 addresses and can ping the default gateway.

Wireguard configuration

Using the configuration file information (generated in step 1):

  • Create a peer (server-side)
  • Create an instance (client-side) and associate it with the peer
  • Enable Wireguard globally
  • Assign the interface (no configuration needed, just assign and enable)

Gateway configuration

Using the DNS IP addresses in the configuration file:

  • Create an IPv4 gateway and an IPv6 gateway
    • Enable Far Gateway
    • Enable Gateway Monitoring with the same IP address

DNS configuration

  • Create an alias for DNS rules later containing all DNS addresses
  • Create port forwarding rule under Firewall → NAT → Destination NAT that redirects any DNS queries from the MINE net to the previous alias

Outbound NAT rules

  • Ensure Hybrid outbound NAT rule generation is enabled (mine was already due to prior Tailscale configuration)
  • Add IPv4 outbound NAT rule that associates the VPN interface to the MINE net
  • Do the same but for IPv6

Firewall rules

I had to fiddle with these a bit because I already had them set up to isolate the MINE network from the rest of my LAN. I also had been putting off the firewall rule migration to OPNsense’s new system, so I had to take care of that before moving forward. Here are the rules I ended up with (in order);

  • In on MINE interface: allow all MINE net to MINE net traffic (to allow internal communication)
  • In on MINE interface: allow all IPv4 MINE net traffic and set the IPv4 gateway
  • In on MINE interface: allow all IPv6 MINE net traffic and set the IPv6 gateway

I disregarded the block all traffic rule as I rely on the default deny and only set explicit Pass rules to allow certain traffic.

Port forwarding

So I went with a VPN provider that allows port forwarding (as unfortunately Mullvad does not), as I figured I would need to port forward to allow 1) other Monero nodes to view my local copy of the blockchain (along the lines of torrenting) on port 18080 and 2) to allow p2pool mining connections over port 37888 or 37889. I haven’t ever opened port 18081 to allow other wallets to connect to my node, just wanted it to contribute to the XMR network.

What I didn’t realize (and probably should have) is that other people almost certainly have those ports reserved already, and I couldn’t use the same one. I would imagine that it’s possible to have my monero node running on a different port than 18080 (let’s say 99999) and have my port forwarding rule translate that external port (18080) to the internal XMR node port (99999), and things would be hunky dory. I don’t think that is going to be possible in reverse - e.g., advertise a different port than 18080 externally, and have other XMR nodes connect via that port instead of the default. Let me correct myself: I imagine it would be possible, but I don’t know if other nodes would connect by default or without some configuration if I’m using a non-default port. In that case, I wouldn’t really be contributing to the network anyway, so I’d rather not go to the trouble until I understand how it might work.

In any case, I will have to do some thinking and research to understand if this is possible. Cursory research didn’t really turn up anything. I believe I can still maintain a full local node copy (it’s currently syncing with seemingly no issues), what I’m pretty sure cannot happen is the external connections to my node. I’d like to enable that if possible, but having it behind a VPN is more important to me at this time.

EOF

Graph View

Backlinks