WireGuard - Revision history

Leo at 18:54, 15 September 2023

2023-09-15T18:54:31Z

@@ Line 3: / Line 3: @@
 ==Installation==
-=== Installing WireGuard ===
+=== Installing WireGuard on RHEL based systems ===
 On CentOS / RHEL / Rocky Linux 8, you will need to install the WireGuard repos and EPEL for DKMS dependencies. {{highlight
 | lang = terminal
@@ Line 17: / Line 17: @@
 # yum-config-manager --enable ol8_developer_EPEL
 # yum install wireguard-dkms wireguard-tools
-}}On Ubuntu, WireGuard is part of the official repos and you simply need to install the package:
+}}
 {{Highlight
 | code = # apt install wireguard
 | lang = terminal
 }}
 == Quick Start ==

Leo at 22:49, 3 February 2022

2022-02-03T22:49:19Z

← Older revision		Revision as of 22:49, 3 February 2022
Line 48:		Line 48:
	Repeat the steps above on another remote endpoint.		Repeat the steps above on another remote endpoint.

	=== Connecting two or more endpoints ===		=== Connecting two (or more) endpoints ===
	After installing WireGuard and configuring wg0 on two or more endpoints, you should have something similar to this:		After installing WireGuard and configuring wg0 on two or more endpoints, you should have something similar to this:
	{\| class="wikitable"		{\| class="wikitable"
Line 84:		Line 84:
	!Site B		!Site B
	\|-		\|-
	\|Determine Site A's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-A-KEY \| wg pubkey</nowiki></code>Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=		\|Determine Site A's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-A-KEY \| wg pubkey</nowiki></code>.
			Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=
	[Peer]		[Peer]
	PublicKey = SITE-B-PUBLIC-KEY		PublicKey = SITE-B-PUBLIC-KEY
Line 95:		Line 96:
	\| lang = terminal		\| lang = terminal
	}}		}}
	\|Determine Site B's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-B-KEY \| wg pubkey</nowiki></code>Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=		\|Determine Site B's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-B-KEY \| wg pubkey</nowiki></code>.
			Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=
	[Peer]		[Peer]
	PublicKey = SITE-A-PUBLIC-KEY		PublicKey = SITE-A-PUBLIC-KEY
Line 108:		Line 110:
	}}		}}
	\|}		\|}
	If everything worked, you should be able to ping each other's private IP address. You should also be able to see each peer's status by running <code>wg show</code>.		If everything worked, you should be able to ping each other's private IP address. You should also be able to see each peer's status by running <code>wg show</code>.
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
	# wg show		# wg show
Line 126:		Line 128:
	Additional peers can be added by repeating the steps above.		Additional peers can be added by repeating the steps above.

	=== ~~Accessing other internal subnets~~ ===		=== Allowed IPs list ===
	~~You may use~~ WireGuard to ~~access private or internal subnets~~. ~~Suppose~~ that ~~Site A has access to a private network 192~~.~~168~~.1.1/~~24 that you wish to~~ access ~~remotely~~.		Each <code>[Peer]</code> entry has a <code>AllowedIPs</code> list which tells WireGuard what traffic can be received from and sent to this endpoint. Any traffic received from this peer that doesn't originate from an address listed in <code>AllowedIPs</code> is dropped. Furthermore, when WireGuard brings up the connection, it will also create routing table entries for each CIDRs listed in the <code>AllowedIPs</code> list. Therefore, as written in the [https://www.wireguard.com/#cryptokey-routing WireGuard documentation]: "when sending packets, the list of allowed IPs behaves as a sort of routing table, and when receiving packets, the list of allowed IPs behaves as a sort of access control list."

	~~To reach 192.168.1~~.~~1/24 from Site B:~~		As a rule of thumb, you will typically see single /32 CIDRs in the AllowedIPs list on servers and one or more CIDR subnets on clients.

	~~# Set up WireGuard on Site A using an unused subnet (eg. Using an endpoint address of 192.168.200.1~~ on a ~~subnet 192.168.200.0/24).~~		For example, you may have a peer defined on a WireGuard server like this:
	~~# Set up~~ WireGuard on Site B and connect it to Site A (eg. with 192.168.200.2). When connecting Site B to Site A, ensure that Site B's allowed-ips list contains both the WireGuard's subnet as well as the private subnet you're trying to access.		{{Highlight
	~~#*On Site A's <code>/etc/wireguard/wg0.conf</code> configuration, ensure AllowedIPs allow these two subnets through:~~{{Highlight
	\| code = [Peer]		\| code = [Peer]
	PublicKey = ~~SITE-B-PUBLIC-KEY~~		PublicKey = xxxx
	Endpoint = ~~SITE-B-EXTERNAL-IP~~:~~5555~~		Endpoint = x.x.x.x:xxxx
	AllowedIPs = 192.168.1.0/24, 192.168.~~200~~.0/24		AllowedIPs = 192.168.1.1/32
			\| lang = terminal
			}}
			This tells WireGuard that this peer will only send traffic that originates from 192.168.1.1 and that all traffic destined for 192.168.1.1 should go to this peer. Any traffic from this peer that doesn't originate from 192.168.1.1 will get dropped. As a result, if you intend to use WireGuard for some sort of NAT application, you'd need to enable masquerading.

			Another example with multiple ranges would look like this:
			{{Highlight
			\| code = [Peer]
			PublicKey = xxxx
			Endpoint = x.x.x.x:xxxx
			AllowedIPs = 192.168.1.0/24, 192.168.10.0/24
	\| lang = terminal		\| lang = terminal
	}}		}}
	#*~~Or run~~:		Similar to the first example, this tells WireGuard that traffic destined to 192.168.1.0/24 and 192.168.10.0/24 should go through to this peer and that traffic from 192.168.1.0/24 and 192.168.10.0/24 can be received from this peer. Because the AllowedIPs also add a routing table entry, you should not have a WireGuard instance where you have multiple peers with overlapping AllowedIPs since traffic would get routed to the first entry in the routing table.

			=== Accessing other internal subnets ===
			In order to access a private/internal subnet using WireGuard, you will need to:

			* On the client-side, specify the internal networks you wish to access under the AllowedIPs list. Subnets listed under the AllowedIPs list will be added as additional routing table entries by WireGuard when the connection is brought up.
			* Enabling masquerading on the server-side so that LAN traffic gets routed back to the client via WireGuard. This can be accomplished by specifying a PostUp/PostDown directive in WireGuard.

			==== Client-side setup ====
			On the client side (that's trying to access the remote internal subnets), edit the peer's AllowedIPs list to include the remote subnets.

			For example, if the you wish to access two networks 192.168.0.0/24 and 192.168.100.0/24 that only the server-side has access to, you would define:
	{{Highlight		{{Highlight
	\| code = ~~# wg set wg0 peer SITE-B-PUBLIC-KEY \~~		\| code = AllowedIPs = 192.168.0.0/24, 192.168.100.0/24
	~~endpoint SITE-B-IP:5555 \~~
	~~allowed-ips~~ 192.168.1.0/24,192.168.~~200~~.0/24
	\| lang = terminal		\| lang = terminal
	}}		}}

			==== Server-side setup ====
			On the server side (that has access to the internal subnets the client is trying to access), edit the [Interface] section to include the following PostUp and PostDown commands, where eth0 is the interface to your 192.168.0.0/24 and 192.168.100.0/24 LANs
			{{Highlight
			\| code = PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
			PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE
			\| lang = text
			}}
			Alternatively, if you don't want to deal with interface names, you may use something like: <code>iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -d 192.168.1.0/24 -j MASQUERADE</code>

	~~# On Site B, create an internal route for 192.168.1.1/24 via 192.168.200.1. This should route everything to the private network via~~ WireGuard.		==== Check your work ====
	~~#*Run~~ on ~~Site B: <code>ip route add 192~~.~~168.1.1/24 via 192.168.200.1</code>~~		Bring WireGuard up on both endpoints. The client side should have a routing table for each of the internal subnets via the WireGuard interface.
	~~# On Site A, traffic destined~~ for ~~192.168.1.1/24~~ via WireGuard ~~should be routed automatically. However, you will want to enable masquerading so that traffic via WireGuard appears to be from the endpoint's local network.~~
	~~#*Run on Site A: <code>iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -d 192.168.1~~.~~0/24 -j MASQUERADE</code>~~

	== Troubleshooting ==		== Troubleshooting ==

Leo at 22:10, 2 February 2022

2022-02-02T22:10:41Z

← Older revision		Revision as of 22:10, 2 February 2022
Line 92:		Line 92:
	\| code = # wg set wg0 peer SITE-B-PUBLIC-KEY \		\| code = # wg set wg0 peer SITE-B-PUBLIC-KEY \
	endpoint SITE-B-IP:5555 \		endpoint SITE-B-IP:5555 \
	allowed-ips 0.0.0.0/0		allowed-ips 192.168.1.2/32
	\| lang = terminal		\| lang = terminal
	}}		}}
Line 104:		Line 104:
	\| code = # wg set wg0 peer SITE-A-PUBLIC-KEY \		\| code = # wg set wg0 peer SITE-A-PUBLIC-KEY \
	endpoint SITE-A-IP:5555 \		endpoint SITE-A-IP:5555 \
	allowed-ips 0.0.0.0/0		allowed-ips 192.168.1.1/32
	\| lang = terminal		\| lang = terminal
	}}		}}
Line 132:		Line 132:

	# Set up WireGuard on Site A using an unused subnet (eg. Using an endpoint address of 192.168.200.1 on a subnet 192.168.200.0/24).		# Set up WireGuard on Site A using an unused subnet (eg. Using an endpoint address of 192.168.200.1 on a subnet 192.168.200.0/24).
	# Set up WireGuard on Site B and connect it to Site A (eg. with 192.168.200.2).		# Set up WireGuard on Site B and connect it to Site A (eg. with 192.168.200.2). When connecting Site B to Site A, ensure that Site B's allowed-ips list contains both the WireGuard's subnet as well as the private subnet you're trying to access.
	#Site A's ~~[Peer] configuration for Site B must have~~ the ~~VPN~~ subnet as well as the private ~~network~~'~~s subnet in the AllowedIPs list. Otherwise, the traffic will get dropped~~.		#*On Site A's <code>/etc/wireguard/wg0.conf</code> configuration, ensure AllowedIPs allow these two subnets through:{{Highlight
	#*On Site A's /etc/wireguard/wg0.conf configuration, ensure AllowedIPs allow these two subnets through:
	{{Highlight
	\| code = [Peer]		\| code = [Peer]
	PublicKey = SITE-B-PUBLIC-KEY		PublicKey = SITE-B-PUBLIC-KEY
	Endpoint = SITE-B-EXTERNAL-IP:5555		Endpoint = SITE-B-EXTERNAL-IP:5555
	AllowedIPs = 192.168.1.1/24,192.168.200.0/24		AllowedIPs = 192.168.1.0/24, 192.168.200.0/24
	\| lang = terminal		\| lang = terminal
	}}		}}
			#*Or run:
			{{Highlight
			\| code = # wg set wg0 peer SITE-B-PUBLIC-KEY \
			endpoint SITE-B-IP:5555 \
			allowed-ips 192.168.1.0/24,192.168.200.0/24
			\| lang = terminal
			}}

	# On Site B, create an internal route for 192.168.1.1/24 via 192.168.200.1. This should route everything to the private network via WireGuard.		# On Site B, create an internal route for 192.168.1.1/24 via 192.168.200.1. This should route everything to the private network via WireGuard.
	#*Run on Site B: <code>ip route add 192.168.1.1/24 via 192.168.200.1</code>		#*Run on Site B: <code>ip route add 192.168.1.1/24 via 192.168.200.1</code>

Leo: /* Accessing other internal subnets */

2022-02-02T22:06:01Z

Accessing other internal subnets

← Older revision		Revision as of 22:06, 2 February 2022
Line 84:		Line 84:
	!Site B		!Site B
	\|-		\|-
	\|Determine Site A's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-A-KEY \| wg pubkey</nowiki></code>		\|Determine Site A's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-A-KEY \| wg pubkey</nowiki></code>Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=

	Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=
	[Peer]		[Peer]
	PublicKey = SITE-B-PUBLIC-KEY		PublicKey = SITE-B-PUBLIC-KEY
Line 97:		Line 95:
	\| lang = terminal		\| lang = terminal
	}}		}}
	\|Determine Site B's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-B-KEY \| wg pubkey</nowiki></code>		\|Determine Site B's public key by reading <code>/etc/wireguard/publickey</code> or by running <code><nowiki>echo SITE-B-KEY \| wg pubkey</nowiki></code>Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=
	Add the following lines to <code>/etc/wireguard/wg0.conf</code> and restart WireGuard.{{highlight\|lang=text\|code=
	[Peer]		[Peer]
	PublicKey = SITE-A-PUBLIC-KEY		PublicKey = SITE-A-PUBLIC-KEY
Line 135:		Line 132:

	# Set up WireGuard on Site A using an unused subnet (eg. Using an endpoint address of 192.168.200.1 on a subnet 192.168.200.0/24).		# Set up WireGuard on Site A using an unused subnet (eg. Using an endpoint address of 192.168.200.1 on a subnet 192.168.200.0/24).
	# Set up WireGuard on Site B and connect it to Site A (eg. with 192.168.200.2)		# Set up WireGuard on Site B and connect it to Site A (eg. with 192.168.200.2).
	# On Site B, create an internal route for 192.168.1.1/24 via 192.168.200.1. This should route everything to the private network via WireGuard. ~~Do this by running~~ on Site B: <code>ip route add 192.168.1.1/24 via 192.168.200.1</code>		#Site A's [Peer] configuration for Site B must have the VPN subnet as well as the private network's subnet in the AllowedIPs list. Otherwise, the traffic will get dropped.
	# On Site A, traffic destined for 192.168.1.1/24 via WireGuard should be routed automatically. However, you will want to enable masquerading so that traffic via WireGuard appears to be from the endpoint's local network.~~. Do this by running~~ on Site A: <code>iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -d 192.168.1.0/24 -j MASQUERADE</code>		#*On Site A's /etc/wireguard/wg0.conf configuration, ensure AllowedIPs allow these two subnets through:
			{{Highlight
			\| code = [Peer]
			PublicKey = SITE-B-PUBLIC-KEY
			Endpoint = SITE-B-EXTERNAL-IP:5555
			AllowedIPs = 192.168.1.1/24,192.168.200.0/24
			\| lang = terminal
			}}
			# On Site B, create an internal route for 192.168.1.1/24 via 192.168.200.1. This should route everything to the private network via WireGuard.
			#*Run on Site B: <code>ip route add 192.168.1.1/24 via 192.168.200.1</code>
			# On Site A, traffic destined for 192.168.1.1/24 via WireGuard should be routed automatically. However, you will want to enable masquerading so that traffic via WireGuard appears to be from the endpoint's local network.
			#*Run on Site A: <code>iptables -t nat -A POSTROUTING -s 192.168.200.0/24 -d 192.168.1.0/24 -j MASQUERADE</code>

	== Troubleshooting ==		== Troubleshooting ==

Leo at 21:59, 2 February 2022

2022-02-02T21:59:00Z

Show changes

Leo at 17:54, 8 October 2021

2021-10-08T17:54:17Z

← Older revision		Revision as of 17:54, 8 October 2021
Line 1:		Line 1:
	WireGuard is an easy to use VPN that provides a secure connection between two parties using public key authentication.		WireGuard is an easy to use VPN that provides a secure connection between two parties using public key authentication.

	== Installation ==		==Installation==
	~~Suppose that we have two sites, Site-A and Site-B, that need to connect to each other on a private subnet.~~

	On CentOS 8:		=== Installing WireGuard ===
	{{highlight\|lang=terminal\|code=		On CentOS 8:{{highlight\|lang=terminal\|code=
	# curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-7/jdoss-wireguard-epel-7.repo		# curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-8/jdoss-wireguard-epel-8.repo
	# yum -y install epel-release		# yum -y install epel-release
	# yum -y update		# yum -y update
Line 12:		Line 11:
	}}		}}

	~~Ensure~~ that ~~you~~ have ~~the latest kernel~~ and ~~kernel development packages so~~ that ~~DKMS is able~~ to ~~build the wireguard kernel module~~.		On OracleLinux 8: {{highlight\|lang=terminal\|code=
			# curl -Lo /etc/yum.repos.d/wireguard.repo https://copr.fedorainfracloud.org/coprs/jdoss/wireguard/repo/epel-8/jdoss-wireguard-epel-8.repo
			# yum -y install oracle-epel-release-el8
			# yum-config-manager --enable ol8_developer_EPEL
			# yum -y update
			# yum install wireguard-dkms wireguard-tools
			}}

			=== Configuration ===
			Suppose that we have two sites, Site-A and Site-B, that need to connect to each other on a private subnet.

	Create a {{code\|wg0.conf}} file in {{code\|/etc/wireguard}}, then generate a new WireGuard key with {{code\|wg genkey}}.		Create a {{code\|wg0.conf}} file in {{code\|/etc/wireguard}}, then generate a new WireGuard key with {{code\|wg genkey}}.
Line 19:		Line 27:
	# (umask 077 && printf "[Interface]\nPrivateKey = " {{!}} sudo tee /etc/wireguard/wg0.conf > /dev/null)		# (umask 077 && printf "[Interface]\nPrivateKey = " {{!}} sudo tee /etc/wireguard/wg0.conf > /dev/null)
	# wg genkey {{!}} sudo tee -a /etc/wireguard/wg0.conf {{!}} wg pubkey {{!}} sudo tee /etc/wireguard/publickey		# wg genkey {{!}} sudo tee -a /etc/wireguard/wg0.conf {{!}} wg pubkey {{!}} sudo tee /etc/wireguard/publickey
	}}		}}Define that local IP address for each site under the Interface section:

	~~=== Connecting to a Remote Site ===~~
	~~Run the installation steps above on both local and remote sites.~~ Define that local IP address for each site under the Interface section:

	Eg. Site-A:		Eg. Site-A:
Line 70:		Line 75:
	Once WireGuard establishes a connection, you should be able to ping the remote site's internal IP address.		Once WireGuard establishes a connection, you should be able to ping the remote site's internal IP address.

	== Usage ==		==Usage==
	Once configured, start the WireGuard service. WireGuard connections can be monitored with {{code\|wg}} or {{code\|wg show}}.		Once configured, start the WireGuard service. WireGuard connections can be monitored with {{code\|wg}} or {{code\|wg show}}.
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
Line 94:		Line 99:
	Config changes only happen when the service is restarted or stopped.		Config changes only happen when the service is restarted or stopped.

	== Troubleshooting ==		==Troubleshooting==
	=== Missing Kernel Module ===		===Missing Kernel Module===
	If the kernel module isn't loading, ensure that you have the proper kernel development package installed for the running kernel. Reinstall the {{code\|wireguard-dkms}} package to trigger a kernel module rebuild. Alternatively, trigger DKMS to rebuild the module with:		If the kernel module isn't loading, ensure that you have the proper kernel development package installed for the running kernel. Reinstall the {{code\|wireguard-dkms}} package to trigger a kernel module rebuild. Alternatively, trigger DKMS to rebuild the module with:
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=
Line 101:		Line 106:
	}}		}}

	=== Connection Timeout ===		===Connection Timeout===
	If your WireGuard connections are dropping or becomes unresponsive, add a {{code\|PersistentKeepalive}} under the {{code\|Peer}} section. Eg:		If your WireGuard connections are dropping or becomes unresponsive, add a {{code\|PersistentKeepalive}} under the {{code\|Peer}} section. Eg:
	{{highlight\|lang=text\|code=		{{highlight\|lang=text\|code=
Line 111:		Line 116:
	}}		}}

	== See Also ==		==See Also==
	* https://www.digitalocean.com/community/tutorials/how-to-create-a-point-to-point-vpn-with-wireguard-on-ubuntu-16-04
	* https://blog.stigok.com/2018/10/08/wireguard-vpn-server-on-centos-7.html		*https://www.digitalocean.com/community/tutorials/how-to-create-a-point-to-point-vpn-with-wireguard-on-ubuntu-16-04
	* https://mikkel.hoegh.org/2019/11/01/home-vpn-server-wireguard/		*https://blog.stigok.com/2018/10/08/wireguard-vpn-server-on-centos-7.html
			*https://mikkel.hoegh.org/2019/11/01/home-vpn-server-wireguard/

	{{Navbox Linux}}[[Category:Linux]]		{{Navbox Linux}}
			[[Category:Linux]]
	[[Category:LinuxUtilities]]		[[Category:LinuxUtilities]]
	[[Category:Networking]]		[[Category:Networking]]

Leo: Added categories

2020-06-14T23:39:19Z

Added categories

← Older revision		Revision as of 23:39, 14 June 2020
Line 115:		Line 115:
	* https://blog.stigok.com/2018/10/08/wireguard-vpn-server-on-centos-7.html		* https://blog.stigok.com/2018/10/08/wireguard-vpn-server-on-centos-7.html
	* https://mikkel.hoegh.org/2019/11/01/home-vpn-server-wireguard/		* https://mikkel.hoegh.org/2019/11/01/home-vpn-server-wireguard/

			{{Navbox Linux}}[[Category:Linux]]
			[[Category:LinuxUtilities]]
			[[Category:Networking]]

Leo at 06:46, 4 November 2019

2019-11-04T06:46:34Z

← Older revision		Revision as of 06:46, 4 November 2019
Line 114:		Line 114:
	* https://www.digitalocean.com/community/tutorials/how-to-create-a-point-to-point-vpn-with-wireguard-on-ubuntu-16-04		* https://www.digitalocean.com/community/tutorials/how-to-create-a-point-to-point-vpn-with-wireguard-on-ubuntu-16-04
	* https://blog.stigok.com/2018/10/08/wireguard-vpn-server-on-centos-7.html		* https://blog.stigok.com/2018/10/08/wireguard-vpn-server-on-centos-7.html
			* https://mikkel.hoegh.org/2019/11/01/home-vpn-server-wireguard/

Leo at 00:20, 4 November 2019

2019-11-04T00:20:59Z

← Older revision		Revision as of 00:20, 4 November 2019
Line 2:		Line 2:

	== Installation ==		== Installation ==
			Suppose that we have two sites, Site-A and Site-B, that need to connect to each other on a private subnet.

	On CentOS 8:		On CentOS 8:
	{{highlight\|lang=terminal\|code=		{{highlight\|lang=terminal\|code=

Leo: /* Usage */

2019-11-04T00:18:15Z

Usage

@@ Line 69: / Line 69: @@
 == Usage ==
 To add an additional peer:
 {{highlight|lang=terminal|code=
 # wg set wg0 peer public_key_of_second_server endpoint public_IP_of_second_server:5555 allowed-ips 192.168.1.X/32