* Update wireguard-client.rst - Add MTU and MSS hints
* Update wireguard-s2s.rst - Add MTU and MSS hints
* Update wireguard-s2s.rst - changed mss values
* Update wireguard-s2s.rst - Reworked How-To completely
* Update wireguard-client.rst - adjusted mss value
* Update wireguard-client.rst - Different mss values for IPv4 and IPv6
* Update wireguard-s2s.rst - Improved some aspects
* Update wireguard-client.rst - Improved some aspects
Normalization rules should have different MSS values for either IPv4, or IPv4+IPv6.
Changed the protocol back to any, since I'm unsure if selecting TCP only means IPv4 TCP, since there is also only IPv6 selectable.
* Update wireguard-s2s.rst
- Omitted Source Port in Firewall rules
- Added tip and note about dynamic WAN IP
* Update wireguard-s2s.rst - Terminology changes 23.7.6
- Changed Local to Instance
- Changed Endpoint to Peer
- Added information about CARP vhid tracking to mitigate HA problems.
- Added note about Keepalive for NATed sites.
@ -31,6 +31,7 @@ Step 2 - Configure the local peer (server)
**Public Key***This will initially be blank; it will be populated once the configuration is saved*
**Private Key***This will initially be blank; it will be populated once the configuration is saved*
**Listen Port***51820 or a higher numbered unique port*
**MTU***1420 (default) or 1412 if you use PPPoE; it's 80 bytes less than your WAN MTU*
**Tunnel Address***For example, 10.10.10.1/24. See note below*
**Peers***The (client) peers will be specified here; leave it blank initially until the Endpoint configuration is created in Step 3*
**Disable Routes***Unchecked*
@ -214,7 +215,48 @@ This will involve two steps - first creating a firewall rule on the WAN interfac
..Note::
If you didn't assign an interface as suggested in Step 5(a), then the second firewall rule outlined above will need to be configured on the automatically created :code:`WireGuard` group that appears once the Local configuration is enabled and WireGuard is started. You will also need to manually specify the source IPs/subnet(s) for the tunnel. It's probably easiest to define an alias (via :menuselection:`Firewall --> Aliases`) for those IPs/subnet(s) and use that. If you have only one local WireGuard instance and only one WireGuard endpoint configured, you can use the default :code:`WireGuard net`, although this is generally not recommended due to unexpected behaviour
------------------------------------
Step 6a - Create normalization rules
------------------------------------
- Go to :menuselection:`Firewall --> Settings -> Normalization` and press **+** to create **one** new normalization rule.
- If you only pass IPv4 traffic through the wireguard tunnel, create the following rule:
- The header size for IPv4 is usually 20 bytes, and for TCP 20 bytes. In total thats 40 bytes for IPv4 TCP.
- IPv6 has a larger header size with 40 bytes. That encreases the total to 60 bytes for IPv6 TCP.
..Note::
By creating the normalization rules, you ensure that IPv4 TCP and IPv6 TCP can pass through the Wireguard tunnel without being fragmented. Otherwise you could get working ICMP and UDP, but some encrypted TCP sessions will refuse to work.
WireGuard is a simple and fast modern VPN protocol. It aims to be faster and less complex than IPSec.
It intends to be considerably more performant than OpenVPN. Initially released for the Linux kernel,
it is now cross-platform and widely deployable.
WireGuard is a simple and fast modern VPN protocol. It aims to be less complicated than IPSec, working more like ssh with private and public keys.
It has fewer lines of code and is more easily audited than other VPN protocols. Initially released for the Linux kernel, it is now cross-platform and widely deployable.
..Attention::
Wireguard is useful for simple routed site to site tunnels and roadwarrior setups. To this date, it doesn't play too nicely with high availability setups. That's because the peer may keep polling a stale interface and misinterpret the other instance as being the one that is down and keep sending traffic there. Also, because Wireguard is bound to all interfaces (and not explicitely the CARP VIP), both High Availability firewalls will send handshakes and fight against each other for the remote Wireguard peer. This behavior was mitigated in 23.7.6 with Wireguard CARP vhid tracking that disables the Wireguard Instance with CARP VIPs in Backup state. In case of critical workloads and high availability, IPsec could still be the better choice.
..Note::
The following example covers an IPv4 Site to Site Wireguard Tunnel between two OPNsense Firewalls with public IPv4 addresses on their WAN interfaces. You will connect *Site A LAN Net*``172.16.0.0/24`` to *Site B LAN Net*``192.168.0.0/24`` using the *Wireguard Transfer Net*``10.2.2.0/24``. *Site A Public IP* is ``203.0.113.1`` and *Site B Public IP* is ``203.0.113.2``.
..Tip::
You can also easily expand this Site to Site tunnel with IPv6 Global Unicast addresses (GUA) or Unique Local Addresses (ULA) to create a Dual Stack tunnel. Just add these IPv6 Networks (usually with /64 Prefix) to the *allowed IPs* and create Firewall rules to allow the traffic.
---------------------
Step 1 - Installation
---------------------
Install the plugin as usual, refresh and page and the you will find the client
via :menuselection:`VPN --> WireGuard`.
Install the os-wireguard plugin in :menuselection:`System --> Firmware --> Plugins`, refresh the GUI and you will soon find :menuselection:`VPN --> WireGuard`.
When this VPN is set up on OPNsense only do the same on the second machine and exchange the public
keys. Now go to tab **Endpoints** and add the remote site, give it a **Name**, insert the **Public
Key** and the **Allowed IPs** e.g. *192.168.0.2/32, 10.10.10.0/24*. This will set the remote tunnel
IP address (/32 is important when using multiple endpoints) and route 10.10.10.0/24 via the tunnel.
**Endpoint Address** is the public IP of the remote site and you can also set optionally the
**Endpoint Port**, now hit **Save changes**.
Press **Save** and **Apply**.
Go back to tab **Local**, open the instance and choose the newly created endpoint in **Peers**.
..Tip::
If one of your sites has a dynamic WAN IP address, you can leave the *Endpoint Address* on the site with the static IP address empty. The site with the dynamic IP will then be the initiator, and the site with the static IP will be the responder. Adjust the Firewall rule accordingly to allow any Source IP to connect to the static site.
Now we can **Enable** the VPN in tab **General** and go on with the setup.
..Note::
If you use hostnames in the *Endpoint Address*, Wireguard will only resolve them once when you start the tunnel. If both sites have dynamic *Endpoint Addresses* set, the tunnel will stop working when they both use DynDNS hostnames, and one (or both) sites receive a new WAN IP lease from the ISP. You could probably mitigate this with a cron job that restarts wireguard periodically.
-----------------------
Step 3 - Setup Firewall
-----------------------
..Note::
If a site is behind NAT, a keepalive has to be set on the site behind the NAT. The keepalive should be 25 seconds as stated in the official wireguard docs. It keeps the UDP session open when no traffic flows, preventing the wireguard tunnel from becoming stale because the outbound port changes.
On :menuselection:`Firewall --> Rules` add a new rule on your WAN interface allowing the port you set in your
instance (Protocol UDP). You also have a new interface **Wireguard** in rules, where you can
set granular rules on connections inside your tunnel.
-------------------------------
Step 4a - Setup Firewall Site A
-------------------------------
Go to :menuselection:`Firewall --> Rules --> WAN` add a new rule to allow incoming wireguard traffic from Site B.
Go to :menuselection:`Firewall --> Settings --> Normalization` and add a new rule to prevent fragmentation of traffic going through the wireguard tunnel.
By creating the normalization rules, you ensure that IPv4 TCP can pass through the Wireguard tunnel without being fragmented. Otherwise you could get working ICMP and UDP, but some encrypted TCP sessions will refuse to work. If you want to use IPv6 TCP, lower the MSS by 60 bytes instead of 40 bytes.
-------------------------------
Step 4b - Setup Firewall Site B
-------------------------------
Go to :menuselection:`Firewall --> Rules --> WAN` add a new rule to allow incoming wireguard traffic from Site A.
Go to :menuselection:`Firewall --> Settings --> Normalization` and add a new rule to prevent fragmentation of traffic going through the wireguard tunnel.
Go to :menuselection:`VPN --> WireGuard --> Settings` on both sites and **Enable WireGuard**
Press **Apply** and check :menuselection:`VPN --> WireGuard --> Diagnostics`. You should see *Send* and *Received* traffic and *Handshake* should be populated by a number. This happens as soon as the first traffic flows between the sites.
If you want to route your internal networks via this VPN just add the network in the field
**Allowed IPs** in **Endpoints** tab (e.g. 10.0.1.0/24).
Press **Save** and **Apply**.
That's it!
..Note::
Now both sites have full access to the LAN of the other Site through the Wireguard Tunnel. For additional networks just add more **Allowed IPs** to the Wireguard Endpoints and adjust the firewall rules to allow the traffic.
Monviech
7 months ago
committed by
GitHub