FreshTomato Wiki

User Tools

Site Tools

Trace:
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 [2025/04/10 22:46] (current) – correct link for wg.sh script pedro
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 8: Line 8:
  
  {{:pasted:20230221-073749.png}}  {{:pasted:20230221-073749.png}}
 +
 +===== Web interface or command-line configuration =====
 +
 +Release 2024.1 and later allow Wireguard configuration in the web interface. Configuration is also still available via command line. Instructions on this wiki page detail how to configure Wireguard via the command-line interface. Instructions for the graphical web interface will follow later. The main principles apply regardless of the interface used.
  
  
 ===== 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 fast performance is possible because code is executed inside kernel-space. Other technologies like OpenVPN, PPTP, or tinc, run in the much slower user-space. Wireguard still uses asymmetric-key technology (like OpenVPN) that is more basic in functionality. However, development is ongoing, and encryption key improvements 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 there's a peer with a forced keepalive option). A new approach 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. By default, Wireguard communicates 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, consult the official documentation's [[https://www.wireguard.com/quickstart/|Quick Start]] guide, and maybe the [[https://github.com/pirate/wireguard-docs|unofficial]] version too.
  
  
 ===== 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:+Wireguard is now available in FreshTomato's web interface since release 2024.1. It is also still available via command line. 
 + 
 +Once you understand some basic principles, it is fairly simple to configure. Currently, only ARM-based devices include the code needed to run Wireguard.
  
  \\  \\
 +
 +=== Checking if Modules are Available/Running ===
 +
 + \\ If you're unsure, try loading the kernel module as follows:
  
 <code -> <code ->
Line 29: Line 39:
 </code> </code>
  
- \\ If you see no output, it means that Wireguard executed.+If you see no output, it means Wireguard executed.
  
- \\ + \\   \\   \\  You should now be able to find it in the list of loaded modules:
- +
-You should now be able to find it in the list of loaded modules: +
- +
- \\+
  
 <code -> <code ->
Line 46: Line 52:
  \\  \\
  
-If Wireguard is not supported on your system, you will see the following error: +If Wireguard isn't supported on your system, you'll see the following error:
- +
- \\+
  
 <code -> <code ->
Line 58: Line 62:
 ===== Syntax ===== ===== Syntax =====
  
-The first step is familiarize yourself with the ''wg'' command. For this, typing: ''wg help'' is a great place to start.+The first step is to familiarize yourself with the ''wg'' command. For this, typing: ''wg help'' is a great place to start.
  
  \\  \\
Line 78: Line 82:
 You may pass `--help' to any of these subcommands to view usage. You may pass `--help' to any of these subcommands to view usage.
 </code> </code>
 +
 + \\
  
  \\  \\
Line 84: Line 90:
  
 For example: For example:
- 
- \\ 
  
 <code -> <code ->
Line 91: Line 95:
 Usage: wg show { <interface> | all | interfaces } [public-key | private-key | listen-port | fwmark | peers | preshared-keys | endpoints | allowed-ips | latest-handshakes | transfer | persistent-keepalive | dump] Usage: wg show { <interface> | all | interfaces } [public-key | private-key | listen-port | fwmark | peers | preshared-keys | endpoints | allowed-ips | latest-handshakes | transfer | persistent-keepalive | dump]
 </code> </code>
 +
 + \\
  
  
 ===== Configuration ===== ===== Configuration =====
  
-There are multiple way wireguard can be set up but in principle you'll need a configuration file (as in VPN configuration, peers, keys, IPs, etc) and a script to initiate the process. The two work hand in hand.+There are many ways Wireguard can be set up. However, in principle, you'll need a configuration file (containing VPN configuration, peers, keys, IPs, and so on) and a script to initiate the process. The two work together.
  
  
-==== 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:+This will illustrate how to achieve a point-to-point connection, the simplest kind.
  
-  * An ARM-based device with Wireguard included in the firmware build. +Let's assume there are two devices with these prerequisites: 
-  * At least one of the devices has a public IP address. + 
-  * DDNS is set up for the device's public IP address (unless you have static addresses). +  * An ARM-based device with Wireguard in the firmware build. 
-  * SSH access is available to both devices. +  * At least one device with a public IP address. 
-  * An alternate method of accessing the router or a host on the LAN accessible via \\ remote access software that doesn't require VPN functionality. The latter is optional \\ but strongly recommended.+  * DDNS configured for the device's public IP address \\ (Unless you have static addresses). 
 +  * SSH access available on both devices. 
 +  * An alternate method of accessing the router, or a host on the LAN \\ accessible via remote access software that doesn't need VPN access. \\ The latter is optional but strongly recommended.
  
  \\  \\
  
-You will need some type of permanent storage so settings will survive a reboot. Here, you have several options, including:+You will need some type of permanent storage so settings will survive a reboot. 
 + 
 +The options include:
  
   * [[nas-usb|USB]]   * [[nas-usb|USB]]
Line 119: Line 129:
  \\  \\
  
-If that storage becomes unavailable, the VPN won't function. For this example, and for the final setup, we will rely on JFFS. Thus, it is assumed you have a JFFS partition mounted in the filesystem of at: "/jffs".+If the storage becomes unavailable, the VPN won't function. 
 + 
 +For this example, and the final setup, we'll use JFFS. It's assumed you have a JFFS partition mounted at: "/jffs".
  
  \\  \\
Line 126: Line 138:
  
 The first step is to create a working pair of keys for each device: The first step is to create a working pair of keys for each device:
- 
- \\ 
  
 <code -> <code ->
Line 135: Line 145:
  
  \\  \\
- 
-The above two key generation programs should have created two files: 
  
  \\  \\
 +
 +The above two key generation programs should create two files:
  
 <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>
  
  \\   \\  \\   \\
  
-The content of these files needs to be added to the configuration file. In this case, we will call that file: ''wg0.conf'':+The content of these files must be added to the configuration file. In this case, we will call that file: "wg0.conf".
  
-Please **do not** use the keys from this example. They are fake/hypothetical and only used as an example.+**Do not** use the keys from this example. They are hypothetical and only an example.
  
- \\ The contents of the wg0.conf file on routerA are as follows: + \\  \\ The contents of the wg0.conf file on routerA are as follows:
- +
- \\+
  
 <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 168: Line 176:
 </code> </code>
  
- \\  \\ The contents of the wg0.conf file on routerB look like this:+ \\  \\  \\
  
- \\+The contents of the wg0.conf file on routerB look like this:
  
 <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 198:
  \\  \\
  
-=== The consequences of having the endpoint sit behind a NAT device ===+=== The Consequences of an Endpoint Sitting behind a NAT Device ===
  
  \\  \\
Line 198: Line 206:
  \\  \\
  
-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), unreachable from the Internet, the connection is initiated from the NAT'd device. However, you must force keepalive activity towards the unNAT'd device to maintain the connection. By default, Wireguard doesn't use keepalive packets. 
 + 
 + \\ 
 + 
 +Let's assume routerB is behind an unmanaged NAT device (your WAN has a private IP). Your routerA [peer] definition in wg0.conf will need to have ''PersistentKeepalive'' defined. Doing this keeps the main router mapping table updated, making the defined Wireguard port reachable.
  
- \\ \\ The necessary changes to the wf0.conf file are seen here: \\+ \\ \\ The necessary changes to wg0.conf for this are: \\
  
 <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 212: Line 224:
  \\  \\
  
-The //PersistentKeepalive// value of 25 seconds represents best practices, since a typical NAT mapping can expire in as little as 30 seconds of inactivity. However, you can try increasing or decreasing this, as needed. Just make certain to monitor the connection stability.+A //PersistentKeepalive// value of 25 seconds is best practice, since a typical NAT mapping can expire in just 30 seconds of inactivity. However, you can adjust this, as needed. Just make sure to to monitor the connection stability when making adjustments.
  
  \\  \\
Line 218: Line 230:
  \\  \\
  
-=== The consequences of having two endpoints sit behind a NAT device ===+=== The Consequences of Having Two Endpoints Sit behind a NAT Device ===
  
  \\  \\
Line 224: Line 236:
 {{:pasted:20230213-144712.png}}\\  \\ {{:pasted:20230213-144712.png}}\\  \\
  
-On a point-to-point connection, we need at least one public IP address or a properly-mapped port. However, it's possible to have two endpoints behind a NAT, as long as they also terminate towards a non-NATed endpoint. The PersistentKeepalive guidance given above will still apply to every NATed endpoint.+On a point-to-point connection, you need at least one public IP address or mapped port. However, it's possible to have two endpoints behind a NAT, if they also terminate towards a non-NAT'd endpoint. The PersistentKeepalive guidance above still applies to every NAT'd endpoint.
  
  
-===== Automated Script with full mesh support =====+===== Automated Script with Full Mesh Support =====
  
-Current version: 1.22\\  \\ +A wizard creates the configuration in this all-in-one solution. It will automate all other steps including key creation, loading, unloading and more. The current version of this script is: 1.22\\  \\  \\
- +
-This all-in-one solution uses a wizard to create the configuration. It will automate all other steps including key creation, loading, unloading and more.\\  \\+
  
 <code -> <code ->
-wget https://tinyurl.com/28b5rckn -O- | tr -d "\r" > /jffs/wg.sh ; chmod 777 /jffs/wg.sh +wget https://gist.githubusercontent.com/pedro0311/548622f1700460b2de8814942e9acbfa/raw/dd5270fac5849b7f9dbbe1ea69289bdf800a7f36/wg.sh -O- | tr -d "\r" > /jffs/wg.sh ; chmod 777 /jffs/wg.sh 
 </code> </code>
  
Line 244: Line 254:
 \\ \\
  
-  * On each device, both the "wg.conf" and "wg0.conf" files reside in the same folder. You needn't/shouldn't  \\ define the path anywhere. The script will know from where it is called. +  * On each device, both the "wg.conf" and "wg0.conf" files are in the same folder. You needn't/shouldn't  \\ have to define the path anywhere. The script will know from where it is called.
-  * 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}}\\+  * 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?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 questions to fully automate the configuration. The result is placed in the: "/tmp/wireguard" folder. Subfolder(s) will be created there, named after the FQDNs of each site created. Each of these folders contains two files:
  
   * wg.sh   * wg.sh
Line 258: Line 267:
  \\  \\
  
-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 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 so 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 ''stop'' parameter option, to unload the Wireguard module and remove any relevant settings it added to the system. Running the script adds a cron reference to selectively check the connectivity of every defined VPN endpoint, and remove it from the routing table. This way, it will not respond. This allows safe fail-back, for example, onto tinc or other VPN protocols/modules.
  
-==== Bringing up the VPN ==== 
  
-Now that we have the "wg.sh" and "wg0.conf" files on each site, we can bring up the VPN simply running ''wg.sh''.  If you do this remotely, you might get disconnected while the script is running. For this reason, you should consider running something like '' { /jffs/wg.sh stop ; /jffs/wg.sh ; } &''  to ensure the script has fully completed (or in this case, restarted). Once the script completes (in about 5-10 seconds), the next step is to verify the last handshake command between the two hosts using the //show// parameter, like this:+==== Starting the VPN ====
  
- \\+Now that we have the "wg.sh" and "wg0.conf" files on each site, we can bring up the VPN simply running ''wg.sh''.  If you do this remotely, you might get disconnected while the script is running. For this reason, you should consider running something like '' { /jffs/wg.sh stop ; /jffs/wg.sh ; } &''  to ensure the script has fully completed (or in this case, restarted). 
 + 
 +Once the script completes (in about 5-10 seconds), the next step is to verify the last handshake command between the two hosts using the //show// parameter, like this:
  
 <code -> <code ->
Line 276: Line 287:
  
 This can be shortened to just ''wg'' , since the //show// parameter is implicit: This can be shortened to just ''wg'' , since the //show// parameter is implicit:
- 
- \\ 
  
 <code -> <code ->
Line 295: Line 304:
  \\  \\
  
-The next step is to ping the remote intra-VPN IP address. For example, from RouterA:  ''ping 192.168.200.2'', then ping the remote LAN IP address. For example, from RouterA: ''ping 10.1.2.1''\\+The next step is to ping the remote intra-VPN IP address. 
 + 
 +For example, from RouterA:  ''ping 192.168.200.2'' 
 + 
 +Then ping the remote LAN IP address for example, from RouterA: ''ping 10.1.2.1''\\
  
  
Line 313: Line 326:
  
  
-==== 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 332: Line 345:
 ==== Running multiple VPN technologies at once ==== ==== Running multiple VPN technologies at once ====
  
-It is generally not a good idea to mix and match different technologies. There are also some resources utilization considerations relating to this, however there may be secondary positive effects to running tinc in the background while Wireguard is running. You could run tinc between all the hosts with a wider network mask, (such as  255.255.0.0) first and then add Wireguard only on specific links (ideally the high performance ones). Having a Wireguard client connect from your mobile phone or a site that uses slow DSL would probably create unwanted overhead. So why use two VPNs at once?+It is generally unwise to mix and match different technologies. There are resource utilization considerations relating to this. However, there can also be secondary //positive// effects to running tinc in the background while Wireguard is running. You could run tinc between all the hosts with a wider network mask, (such as  255.255.0.0) first and then add Wireguard only on specific links (ideally, the high performance ones). 
 + 
 +Having a Wireguard client connect from a mobile phone or a site that uses slow DSL could create unwanted overhead. So why use two VPNs at once?
  
  \\ \\  {{:pasted:20230213-091756.png}}\\  \\  \\ \\  {{:pasted:20230213-091756.png}}\\  \\
  
-Let's say we have five sites, all connected over tinc (green) and three of them have high speed connectivity where we decide to add Wireguard (blue). We now now find ourselves in the situation shown above.+Let's assume we have five sites connected via tinc (green). Three of these sites have high speed connectivity where we decide to add Wireguard (blue). We now now find ourselves in the situation illustrated above.
  
- \\ \\ If something happens to Wireguard (say, a storage failure where the script is) and Site A gets disconnected, its now unreachable. This is illustrated in the diagram below by red stars to represent the broken links:+ \\ \\ If something were to cause a Wireguard failure (say, storage of the script) and Site A were to be disconnected, it would now be unreachable. This is illustrated in the diagram below, in which red stars represent the broken links:
  
- \\ \\  {{:pasted:20230213-092742.png}}\\  \\+ \\ {{:pasted:20230213-092742.png}}\\  \\
  
-However, let's say the addressing were done in a certain way:+However, what if addressing was done such that:
  
-  * A "/16" netmask was used for global tinc, so there would be a single /16 netmask \\ for your whole tinc network in the routing table) and; +  * A "/16" netmask was used for global tinc. This would result in a single /16 netmask \\ for your whole tinc network in the routing table) and; 
-  * A "/24" netmask was used for each individual Wireguard link+  * A "/24" netmask was used for each individual Wireguard link.
  
- \\+ \\ Under these conditions, the tinc-only devices could greatly increase resilience and redundancy.
  
-Under those conditions, the tinc-only devices could play a very important role in resilience/redundancy. +If the Wireguard script is up ("wg0" device exists), that could allow you to connect via SSH into a tinc-only device (say, Site E). From there, you could use SSH to connect to Site A again to fix the issue.
- +
-If the Wireguard script is up (the "wg0" device exists), it could allow you to connect via SSH into a tinc-only device (say, Site E). From there, you could use SSH to connect to Site A again to fix the issue.+
  
  \\  \\
Line 357: Line 370:
 === Routing verification === === Routing verification ===
  
-When your routing table has multiple options to reach a destination, a good way to verify this is to use the built-in ''ip route'' command. In the same example, with two VPN technologies running at once, you can verify the routing table's elected path, like this:\\+When your routing table has multiple options to reach a destination, a good way to verify this is to use the built-in ''ip route'' command. 
 + 
 +In the same example, with two VPN technologies running at once, you can verify the routing table's elected path, like this:\\
  
 ''ip route get x.x.x.x'' ''ip route get x.x.x.x''
Line 384: Line 399:
  
 to the following: to the following:
 +
 + \\
  
 <code -> <code ->
Line 391: Line 408:
 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 420:
  \\  \\
  
-Remember also that  ''wg'' is a shortcut to using ''wg show'' and will display helpful information, for example:+ \\
  
- \\ \\ {{:pasted:20230213-133121.png}} \\ \\+Remember that  ''wg'' is a shortcut to using ''wg show'' and displays helpful information, as seen below:
  
-However, you can also display advanced information by using:+\\ {{:pasted:20230213-133121.png}} \\ \\
  
- \\+You can also display more advanced information by using:
  
 <code -> <code ->
 root@routera:/# wg show all dump root@routera:/# wg show all dump
 +</code>
 +
 + \\ 
 + \\ If there's no issue with the VPN, there might be a routing problem which can be verified using the route subcommand:
 +
 +<code ->
 +root@routera:/# route
 </code> </code>
  
  \\  \\
  
-If there's no issue with the VPN, there might be a routing problem which can be verified using the route subcommand:+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. 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 ====
  
  \\  \\
  
-<code -> +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.
-root@routera:/# route +
-</code>+
  
  \\  \\
  
-Pinging the intra-VPN IP address first will help to identify if Wireguard is the issue or if it is routing-related.\\  \\+{{:pasted:20230213-152337.png}}\\  \\
  
-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.+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: by hogwild

Page Tools

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki