Skip to main content

Remote Access

Allowing remote access is just a matter of setting up a new Wireguard interface, allowing incoming traffic to that interface, and making sure the firewall allows that traffic to connect to the rest of the network.

Create Interface

# cd /etc/wireguard
# umask 077
# wg genkey | tee guard.key | wg pubkey > guard.pub
# printf "[Interface]\PrivateKey = %s\n" `cat guard.key`

Then I modified my file to finish configuring the interface and allow a [Peer] for my laptop.

# /etc/wireguard/guard.conf
[Interface]
PrivateKey = ****
+ Address = 10.0.2.1/28, 2001:db8:2ebf:2::1/64
+ ListenPort = 51820
+
+ [Peer]
+ PublicKey = Iz5ceR0+tCN3BLTWehZxSplzdbABRT8geqifFxubHUA=
+ AllowedIPs = 10.0.2.4,4/32, 2001:db8:2ebf:1::4/128
+ PresharedKey = ***

Line 4: Sets an IPv4 and IPv6 address for this interface. These will be the servers IPs on each virtual subnet.

Line 5: Sets the port to listen to for this interface. It is just the default Wirgaurd port and I'll allow traffic through the firewall for it soon.

Line 7-10: Declare a peer, define the public key to use when communicating and validaing any connections, set what IPs it is allowed to use on each virtual subnet, and configure a pre-shared key for additional secuirty.

A preshard key can be generated by running wg genpsk and must be set on both the [Peer] block on the server and the [Interface] block on the client.

Line

Firewall 5: All rules/routes should be applied to a custom route table 9. I could have also named my custom route table by running echo "9 warp" > /etc/iproute2/rt_tables and then say Table = warp for improved readability.

Line 6: Adds rules for IPv4 and IPv6 that all traffic coming in interface eth1.9 should use custom route table 9. Because I defined a peer with AllowedIPs = 0.0.0.0/0 a default route will be setup on custom route table 9 that redirects all traffic to the Wireguard interface. If I named my custom route like shown above I could have said lookup warp inplace of lookup 9.

Line 7: Just the inverse of line 5 to clean up after ourselves when taking down the Wireguard interface.

Setup IP MasqueradingConfiguration

IP Masquerading is a technique that hides an entire IP address space, usually consisting of private IP addresses, behind a single IP address in another, usually public address space.

Source: Wikipedia

Configuration

The easiest way to set this up are to append some netfilter rules to the PostUp and PreDown parameters.

...
PostUp = ...; iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
PreDown = ...; iptables -t nat -D POSTROUTING -o wg0 -j MASQUERADE

[Peer]
...

Although this works you risk the iptables/netfilter rules getting squashed by Shorewall when if it is restarted while the Wireguard interface exists. It is best to have Shorewall setup the masquerading by making a simple declaration in /etc/shorewall/snat. I've included the other Shorewall configuration files that would be necessary to make this setup work.

First I definehad theto wgdeclare zone…

a 
#new /etc/shorewall/zonesinterface #ZONEand TYPE    OPTIONS                 IN                      OUT
  #                                       OPTIONS                 OPTIONS
  warp    ipv4
+ wg      ipv4

Thensince I definewant theit interfaceto WG_IFbe andas if I was sitting on my laptop at home, I put it in the wglan zone…zone.

# /etc/shorewall/interfaces
...
 #ZONE	INTERFACE	OPTIONS
warp...
 WARP_IFwg	WGAZSE1_IF	tcpflags,nosmurfs,routefilter=2,routefilter,logmartians,physical=eth1.9wgazse1
+ lan	WGGUARD_IF	tcpflags,nosmurfs,routefilter,logmartians,physical=wgguard

# /etc/shorewall/interfaces
...
 #ZONE	INTERFACE	OPTIONS
...
 wg	WG_IFWGAZSE1_IF	tcpflags,nosmurfs,routefilter,logmartians,physical=wg0wgazse1
+ lan	WGGUARD_IF	tcpflags,forward=1,physical=wgguard

ThisFor tellsoutside Shorwallclients to masqueradeconnect allI IPsneed goingto outadd a rule that allows them to connect to port 51820.

# /etc/shorewall[6]/rules
+ ACCEPT          wan,lan         $FW             udp             51820

The last step is to once again setup masquerading so traffic from clients on the virtual subnet have appear to be coming originating from the WG_IFwgguard… interface which is in the lan zone.

# /etc/shorewall/snat
#ACTION		SOURCE		DEST
+ MASQUERADE		10.0.0.0.2.0/024		WG_IFWAN_IF,LAN_IF,DMZ_IF

Then I allow the warp zone to send packets to the wg zone. The warp zone isn't allowed to send packets to any other subnet or the wan. This prevents any data/privacy spills from happening if the Wireguard interface ever goes down. It is always best to fail into a state that protects security and privacy.

# /etc/shorewall/policyshorewall6/snat
#SOURCEMASQUERADE		DESTfde9:2375:2ebf:2::/64	POLICY          LOGLEVEL        RATE    CONNLIMIT
- warp		$FW			ACCEPT          $LOG_LEVEL
+ warp		$FW,wg		ACCEPT          $LOG_LEVELWAN_IF,LAN_IF,DMZ_IF
Back to top