Site Tools


wireguard_on_freshtomato

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
wireguard_on_freshtomato [2023/07/17 01:30] – [Introduction] -condense, change link label to "Quick Start", as per original hogwildwireguard_on_freshtomato [2024/04/28 16:55] (current) – [Introduction] -remove right bracket hogwild
Line 1: Line 1:
 ====== Wireguard ====== ====== Wireguard ======
  
-Wireguard is a revolutionary VPN technology that allows for very fast throughput lowe latency compared to traditional VPN technologies.+Wireguard is a revolutionary VPN technology that allows for very fast throughput with low latency compared to traditional VPN technologies.
  
 Here are some rough benchmarks that illustrate the performance differences: Here are some rough benchmarks that illustrate the performance differences:
Line 12: Line 12:
 ===== Introduction ===== ===== Introduction =====
  
-Wireguard's exceptional performance is possible because the code is executed within kernel-space. Other technologies, such as OpenVPN, PPTP, or tinc run in user-space which is much slower. Wireguard still uses asymmetric-key technology (similar to OpenVPN) that is more basic in functionality. However, a lot of development is going on right now, and improvements in encryption keys are expected soon.+Wireguard's exceptional performance is possible because the code is executed within kernel-space. Other technologies, such as OpenVPN, PPTP, or tinc run in user-space which is much slower. Wireguard still uses asymmetric-key technology (similar to OpenVPN) that is more basic in functionality. However, there is a lot of ongoing development, and improvements in encryption keys are expected soon.
  
-Wireguard is not a "talkative" protocol. It tends to send data only when needed (unless a peer is defined with a forced keepalive option). One new approach taken with Wireguard was to completely remove handshaking. Now, data is accepted only if the decryption key works. This makes Wireguard less "chatty", simpler and faster). Wireguard communicates by default over UDP port 51820.+Wireguard is not a "talkative" protocol. It tends to send data only when needed (unless a peer is defined with a forced keepalive option). One new approach taken with Wireguard was to completely remove handshaking. Now, data is accepted only if the decryption key works. This makes Wireguard less "chatty", simpler and faster. Wireguard communicates by default over UDP port 51820.
  
 Before configuring Wireguard, you should consult the official documentation's [[https://www.wireguard.com/quickstart/|Quick Start]] guide, and possibly the [[https://github.com/pirate/wireguard-docs|unofficial]] version as well. Before configuring Wireguard, you should consult the official documentation's [[https://www.wireguard.com/quickstart/|Quick Start]] guide, and possibly the [[https://github.com/pirate/wireguard-docs|unofficial]] version as well.
Line 21: Line 21:
 ===== Overview ===== ===== Overview =====
  
-Until a graphical interface is developed for FreshTomato, Wireguard is available only via command line. Once the basic principles are understood, configuring Wireguard is relatively simple. There are just a few caveats to be aware of. Currently, only ARM-based devices include the code needed to run Wireguard. If you're unsure, you can try loading the kernel module as follows:+Until Wireguard is integrated into FreshTomato's web interfaceit is available only via command line. However, once you understand some basic principles, configuring Wireguard is relatively simple. There are just a few caveats to be aware of. Currently, only ARM-based devices include the code needed to run Wireguard. If you're unsure, you can try loading the kernel module as follows:
  
  \\  \\
Line 98: Line 98:
  
  
-==== Point-to-point ====+==== Point-to-Point Connection ====
  
 Here, we will illustrate how to achieve a point-to-point connection, the simplest kind. Let's assume we have two devices with these prerequisites: Here, we will illustrate how to achieve a point-to-point connection, the simplest kind. Let's assume we have two devices with these prerequisites:
Line 142: Line 142:
 <code -> <code ->
 root@routerA:/jffs# ls -l root@routerA:/jffs# ls -l
--rw-r--r--    1 root     root            45 Feb 13 10:51 privateKey_routera +-rw-r--r--    1 root     root            45 Feb 13 10:51 privateKey_routerA 
--rw-r--r--    1 root     root            45 Feb 13 10:51 publicKey_routera+-rw-r--r--    1 root     root            45 Feb 13 10:51 publicKey_routerA
 </code> </code>
  
Line 158: Line 158:
 <code -> <code ->
 root@routerA:/jffs# cat wg0.conf root@routerA:/jffs# cat wg0.conf
-[Interface] # RouterA = local +[Interface] # routerA = local 
-PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/f7dd+/0HkbCR1YMDakU= # This is the generated privateKeyroutera on the local router+PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/f7dd+/0HkbCR1YMDakU= # This is the generated privateKeyrouterA on the local router
 ListenPort = 51820 # Default port this router listen to, but can be changed if needed ListenPort = 51820 # Default port this router listen to, but can be changed if needed
  
Line 174: Line 174:
 <code -> <code ->
 root@routerB:/jffs# cat wg0.conf root@routerB:/jffs# cat wg0.conf
-[Interface] # RouterB = local +[Interface] # routerB = local 
-PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/f7dd+/0HkbCR1YMDakU= # This is the generated privateKeyrouterb on the local router+PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/f7dd+/0HkbCR1YMDakU= # This is the generated privateKeyrouterB on the local router
 ListenPort = 51820 # Default port this router listen to, but can be changed if needed ListenPort = 51820 # Default port this router listen to, but can be changed if needed
  
-[peer] # RouterA = remote+[peer] # routerA = remote
 Endpoint = rtra.ddns.org:51820 # FDQN:port of Router A Endpoint = rtra.ddns.org:51820 # FDQN:port of Router A
 PublicKey = Pr1EV/OukTXsj0eeEM96mOCW4Jy00iUMIFp24Z93owo= # This is the public key as generated on the remote device. PublicKey = Pr1EV/OukTXsj0eeEM96mOCW4Jy00iUMIFp24Z93owo= # This is the public key as generated on the remote device.
Line 190: Line 190:
  \\  \\
  
-=== The consequences of having the endpoint sit behind a NAT device ===+=== The Consequences of the Endpoint Sitting behind a NAT Device ===
  
  \\  \\
Line 198: Line 198:
  \\  \\
  
-On a network with private addressing (behind NAT) that isn't reachable from the Internet, the connection will be initiated from the NATed device. However, you'll need to force keepalive activity towards the unNATed device to maintain the connection. Remember, by default, Wireguard doesn't use keepalive packets. Let's assume RouterB is behind an unmanaged NAT device (so your WAN has a private IP) your router A [peer] definition within wg0.conf will need to have the ''PersistentKeepalive'' defined. Doing this allows the main router mapping table to stay updated, and make the defined Wireguard port reachable.+On a network with private addressing (behind NAT) that isn't reachable from the Internet, the connection will be initiated from the NATed device. However, you'll need to force keepalive activity towards the unNATed device to maintain the connection. Remember, by default, Wireguard doesn't use keepalive packets. Let's assume routerB is behind an unmanaged NAT device (so your WAN has a private IP) your routerA [peer] definition within wg0.conf will need to have the ''PersistentKeepalive'' defined. Doing this allows the main router mapping table to stay updated, and make the defined Wireguard port reachable.
  
- \\ \\ The necessary changes to the wf0.conf file are seen here: \\+ \\ \\ The necessary changes to the wg0.conf file for this are seen here: \\  \\
  
 <code -> <code ->
-[peer] # RouterA = remote+[peer] # routerA = remote
 Endpoint = rtra.ddns.org:51820 Endpoint = rtra.ddns.org:51820
 PublicKey = Pr1EV/OukTXsj0eeEM96mOCW4Jy00iUMIFp24Z93owo= PublicKey = Pr1EV/OukTXsj0eeEM96mOCW4Jy00iUMIFp24Z93owo=
Line 218: Line 218:
  \\  \\
  
-=== The consequences of having two endpoints sit behind a NAT device ===+=== The Consequences of Having Two Endpoints Sit behind a NAT Device ===
  
  \\  \\
Line 227: Line 227:
  
  
-===== Automated Script with full mesh support =====+===== Automated Script with Full Mesh Support =====
  
 Current version: 1.22\\  \\ Current version: 1.22\\  \\
Line 247: Line 247:
   * The wg.sh and "wg0.conf" files are complete and require no modification. The entire configuration is \\ automatically generated and stored in the "wg0.conf" file.   * The wg.sh and "wg0.conf" files are complete and require no modification. The entire configuration is \\ automatically generated and stored in the "wg0.conf" file.
  
- \\ \\ {{:pasted:20230324-065819.png}}\\+ \\ \\ {{:pasted:20230324-065819.png?580}}\\  \\   \\  The script will display an introduction screen:
  
-\\ {{:pasted:20230326-205524.png}}\\  \\  \\+ \\ {{:pasted:20230326-205524.png?852}}\\  \\  \\
  
 Running "wg.sh" with the //makeconf//  parameter will guide you through some questions to fully automate the configuration. The result is placed in the: "/tmp/wireguard" folder. Subfolder(s) will be created there, named after the FQDN(s) of each site that is created. Each of these folders contains two files: Running "wg.sh" with the //makeconf//  parameter will guide you through some questions to fully automate the configuration. The result is placed in the: "/tmp/wireguard" folder. Subfolder(s) will be created there, named after the FQDN(s) of each site that is created. Each of these folders contains two files:
Line 260: Line 260:
 You do not need to make any changes to those files. Simply copy them both to the relevant device (preferably jffs). This means you must run the makeconf on any one (and only one) device.\\ You do not need to make any changes to those files. Simply copy them both to the relevant device (preferably jffs). This means you must run the makeconf on any one (and only one) device.\\
  
-The wg.sh script has been written such that it can be run multiple times, even consecutively. Router and iptables/router rules that are already present in the configuration it creates will not be added again. The script also supports an optional  ''stop''  parameter to unload the wireguard module and remove any relevant configuration it added to the system. Running the script will add a cron reference to selectively check the reachability of every defined VPN endpoint, and remove it from the routing table is they are not to respond. This allows safe fail-back, for example, onto tinc or another VPN protocol/module.+The wg.sh script has been written such that it can be run multiple times, even consecutively. Router and iptables/router rules that are already present in the configuration it creates will not be added again. The script also supports an optional  ''stop''  parameter to unload the wireguard module and remove any relevant configuration it added to the system. Running the script will add a cron reference to selectively check the reachability of every defined VPN endpoint, and remove it from the routing table so it will not respond. This allows safe fail-back, for example, onto tinc or another VPN protocol/module.
  
  
Line 313: Line 313:
  
  
-==== Running the Wireguard VPN at boot ====+==== Running Wireguard at Boot ====
  
 As hinted previously, you must rely on permanent storage to make this work. Regardless of what type of storage you choose, it might become unavailable. For this reason, [[jffs|JFFS]] has been used throughout the examples, as it arguably the most reliable form. To run Wireguard automatically, place this line in the Firewall field in the //Administration///[[admin-scripts|Scripts]] menu: As hinted previously, you must rely on permanent storage to make this work. Regardless of what type of storage you choose, it might become unavailable. For this reason, [[jffs|JFFS]] has been used throughout the examples, as it arguably the most reliable form. To run Wireguard automatically, place this line in the Firewall field in the //Administration///[[admin-scripts|Scripts]] menu:
Line 376: Line 376:
  
 If any problems arise while running the script, you should consider changing the first line from: If any problems arise while running the script, you should consider changing the first line from:
 +
 + \\
  
 <code -> <code ->
Line 384: Line 386:
  
 to the following: to the following:
 +
 + \\
  
 <code -> <code ->
Line 390: Line 394:
  
 Using the script with the "-x" option causes it to run in trace (debug) mode. Using the script with the "-x" option causes it to run in trace (debug) mode.
- 
-Remember that you can get help with any subcommand by typing: 
  
  \\  \\
 +
 +Remember that you can get help with any subcommand by typing:\\  \\
  
 <code -> <code ->
Line 401: Line 405:
  \\  \\
  
-Remember also that  ''wg'' is a shortcut to using ''wg show'' and will display helpful information, for example:+Remember also that  ''wg'' is a shortcut to using ''wg show'' and will display helpful information, as seen below:
  
  \\ \\ {{:pasted:20230213-133121.png}} \\ \\  \\ \\ {{:pasted:20230213-133121.png}} \\ \\
  
-However, you can also display advanced information by using:+You can also display more advanced information by using:
  
  \\  \\
Line 425: Line 429:
  \\  \\
  
-Pinging the intra-VPN IP address first will help to identify if Wireguard is the issue or if it is routing-related.\\  \\+Pinging the intra-VPN IP address first will help to identify if Wireguard is the issue or if it is routing-related.\\  \\ Finally, pay attention to the //AllowedIPs// field in the configuration. There, each intra-vpn router's IP address is defined with a /32 subnet. However, in the wg.sh script, a /24 subnet is used. This is meant.
  
-Finally, pay attention to the //AllowedIPs// field in the configuration. There, each intra-vpn router's IP address is defined with a /32 subnet. However, in the wg.sh script, a /24 subnet is used. This is meant. 
  
 +==== Known Bugs ====
 +
 + \\
 +
 +With the current version of the code (v1.0.20200827), if you use the ''wg'' ("wg show") command, it appears as if sent traffic is not counted as it should be.
 +
 + \\
 +
 +{{:pasted:20230213-152337.png}}\\  \\
 +
 +This should be fixed in a later version of the code.
 +
 + \\
 +
 + \\
  
-==== Known bugs ==== 
-On the current version of the code: 
-<code ->root@router:/# wg --version 
-wireguard-tools v1.0.20200827 - https://git.zx2c4.com/wireguard-tools/</code> 
  
-{{:pasted:20230213-152337.png}}\\ 
-Using the wg (a.k.a. wg show) command it appears like the sent traffic is not counted as it should. 
wireguard_on_freshtomato.1689553814.txt.gz · Last modified: 2023/07/17 01:30 by hogwild