This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revisionNext revisionBoth sides next revision | ||
wireguard_on_freshtomato [2023/07/17 00:44] – [Point-to-point] -grammar hogwild | wireguard_on_freshtomato [2023/09/24 23:41] – [Introduction] -condense hogwild | ||
---|---|---|---|
Line 12: | Line 12: | ||
===== Introduction ===== | ===== Introduction ===== | ||
- | Wireguard' | + | Wireguard' |
Wireguard is not a " | Wireguard is not a " | ||
- | Before configuring Wireguard, | + | Before configuring Wireguard, |
===== Overview ===== | ===== Overview ===== | ||
- | Until a graphical interface | + | Until Wireguard |
\\ | \\ | ||
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:/ | root@routerA:/ | ||
- | -rw-r--r-- | + | -rw-r--r-- |
- | -rw-r--r-- | + | -rw-r--r-- |
</ | </ | ||
Line 158: | Line 158: | ||
<code -> | <code -> | ||
root@routerA:/ | root@routerA:/ | ||
- | [Interface] # RouterA | + | [Interface] # routerA |
- | PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/ | + | PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/ |
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:/ | root@routerB:/ | ||
- | [Interface] # RouterB | + | [Interface] # routerB |
- | PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/ | + | PrivateKey = WOOgLRpUxq3XjGfuP79JHKR/ |
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 | + | [peer] # routerA |
Endpoint = rtra.ddns.org: | Endpoint = rtra.ddns.org: | ||
PublicKey = Pr1EV/ | PublicKey = Pr1EV/ | ||
Line 190: | Line 190: | ||
\\ | \\ | ||
- | === The consequences | + | === The Consequences |
\\ | \\ | ||
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' | + | 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' |
- | \\ \\ 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 | + | [peer] # routerA |
Endpoint = rtra.ddns.org: | Endpoint = rtra.ddns.org: | ||
PublicKey = Pr1EV/ | PublicKey = Pr1EV/ | ||
Line 218: | Line 218: | ||
\\ | \\ | ||
- | === The consequences | + | === The Consequences |
\\ | \\ | ||
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 " | * The wg.sh and " | ||
- | \\ \\ {{: | + | \\ \\ {{: |
- | \\ {{: | + | \\ {{: |
Running " | Running " | ||
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/ | + | The wg.sh script has been written such that it can be run multiple times, even consecutively. Router and iptables/ |
Line 300: | Line 300: | ||
==== DNS Resolution ==== | ==== DNS Resolution ==== | ||
- | As with other VPN technologies, if you want the local DNS server to respond to DNS queries from other VPN sites, you need to tell dnsmasq to enable listening | + | As with other VPN protocols, if you want the local DNS server to respond to DNS queries from other VPN sites, you must tell dnsmasq to listen |
\\ | \\ | ||
Line 309: | Line 309: | ||
\\ | \\ | ||
- | |||
\\ | \\ | ||
- | ==== Running | + | |
+ | ==== 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, | 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, | ||
Line 330: | Line 330: | ||
- | ==== Multiple | + | ==== Running multiple |
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 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? | ||
- | \\ \\ {{: | + | \\ \\ {{: |
- | Let's say we have five sites, all connected over tinc (green) and three of them have high speed connectivity where I decide to add Wireguard (blue). | + | 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). |
- | \\ \\ Now, if something happens to Wireguard (say, a storage failure where the script | + | \\ \\ If something happens to Wireguard (say, a storage failure where the script |
\\ \\ {{: | \\ \\ {{: | ||
- | However, let's say the addressing were done a certain way: | + | However, let's say the addressing were done in a certain way: |
- | * A "/ | + | * A "/ |
* A "/ | * A "/ | ||
- | In this case, the tinc-only devices | + | \\ |
+ | |||
+ | Under those conditions, the tinc-only devices | ||
- | If the wireguard | + | If the Wireguard |
\\ | \\ | ||
Line 371: | Line 373: | ||
- | ===== Notes and Troubleshooting ===== | + | ===== Wireguard |
- | If any issue is experienced | + | If any problems arise while running the script, |
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 379: | Line 383: | ||
</ | </ | ||
- | to | + | \\ |
+ | |||
+ | to the following: | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 385: | Line 393: | ||
</ | </ | ||
- | this will run the script in trace (debug) mode. | + | Using the script |
+ | |||
+ | \\ | ||
+ | |||
+ | Remember that you can get help with any subcommand by typing: | ||
<code -> | <code -> | ||
Line 391: | Line 403: | ||
</ | </ | ||
- | is your friend and remember | + | \\ |
+ | |||
+ | Remember also that | ||
+ | |||
+ | | ||
+ | |||
+ | You can also display more advanced | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 397: | Line 417: | ||
</ | </ | ||
- | If there' | + | \\ |
+ | |||
+ | If there' | ||
+ | |||
+ | \\ | ||
<code -> | <code -> | ||
Line 403: | Line 427: | ||
</ | </ | ||
- | Pinging the intra-VPN Ip address first will help understanding is the issue is wireguard or rather routing related.\\ | + | \\ |
+ | Pinging the intra-VPN IP address first will help to identify if Wireguard is the issue or if it is routing-related.\\ | ||
+ | |||
+ | |||
+ | ==== Known Bugs ==== | ||
+ | |||
+ | \\ | ||
+ | |||
+ | With the current version of the code (v1.0.20200827), | ||
+ | |||
+ | \\ | ||
+ | |||
+ | {{: | ||
+ | |||
+ | This should be fixed in a later version of the code. | ||
+ | |||
+ | \\ | ||
+ | |||
+ | \\ | ||
- | ==== Known bugs ==== | ||
- | On the current version of the code: | ||
- | <code -> | ||
- | wireguard-tools v1.0.20200827 - https:// | ||
- | {{: | ||
- | Using the wg (a.k.a. wg show) command it appears like the sent traffic is not counted as it should. |