How to Create a Site to Site VPN // OpenWrt, Wireguard
ฝัง
- เผยแพร่เมื่อ 15 ก.ค. 2024
- Support Me
Get a 5% off Ekster Products
shop.ekster.com/devodyssey or discount code "DEV" at checkout!
(PAID Link)
Follow me on Twitter and Facebook
/ dev_odyssey
/ dev0dyssey
We're all aware of how VPNs are used for privacy, geographic specific content, and hiding your IP. But VPNs have many other use cases, and a big one is site to site VPNs. What this does, is connect your networks together as if they all come from the same firewall. Corporations have been using site to site VPNs for quite some time, to connect their remote office networks together. However, this tech isn't just for big business; you too can set up a site to site VPN in your personal networks. You can set them up to connect family networks, friend's networks, or personal business networks together. This makes management of these networks convenient, and secure using strong encryption behind VPNs. In particular, Wireguard is well suited for site to site VPNs, with strong encryption, and low latency.
Setting up your own site to site VPN with Wireguard is easy. While I demonstrate this with OpenWrt, you can do this easily with most Linux distros, such as Raspberry Pi OS, or BSD based distributions like OPNsense, pfSense, or even FreeBSD. The configuration used here, and theory, will carry over to any distribution you choose, and has been curated with best security practices in mind. From here, you can create additional security policies that let you shape and control your traffic and access the way you want it. In the future, this will be helpful in learning mesh and overlay networking.
Watch this video to start joining your networks for convenience and management ease!
Links
Automated WireGuard Site to Site VPN configuration
openwrt.org/docs/guide-user/s...
Forward Zones and Forward Rules Reference
forum.openwrt.org/t/firewall-...
Wireguard Reference
www.wireguard.com
Site A Configuration
gist.github.com/odevodyssey/7...
Site B Configuration
gist.github.com/odevodyssey/1...
OpenWrt (21.02) Packages Used
luci-wireguard-app + dependencies (in the link below)
openwrt.org/packages/pkgdata/...
00:00 Intro
01:11 Site to Site VPN Diagram
04:56 Site to Site VPN Uses
05:54 Hardware / Software
06:13 Demo Foreward
07:51 Demonstration / Site A Config
11:17 Site B Config
17:29 Finish Site A Config
20:00 Verifying / Testing
22:40 Site to Site VPN Benefits
23:11 Final Thoughts / Alternatives
24:05 Outro
Music | "Get Away" by LiQWYD
Watch: • LiQWYD - Get Away [Off...
License: www.liqwydmusic.com/how-to-use
Download/Stream: hypeddit.com/liqwyd/get-away
OpenWrt is a registered trademark owned by Software Freedom Conservancy (SFC)
WireGuard is a registered trademark of Jason A. Donenfeld
#OpenWrt #Wireguard #Site2Site #VPN #site-to-site - วิทยาศาสตร์และเทคโนโลยี
![[UNCUT] ลูกหมี-ลิลลี่ เหงียน เปิดใจฟาด ปู มัณฑนา I คนดังนั่งเคลียร์ I 15 ก.ค.67](http://i.ytimg.com/vi/FKQ60Y7bJ6s/mqdefault.jpg)
This actually helped. Thanks a lot. My setup took longer - I am using Dynamic DNS for the gateway public IPs, but once that was working properly and I had properly configured the AT&T BGW210 gateways, it finally is working. Now I can access hosts at my office from home, and at my home from office.
Thanks for watching and the compliment @schematica! You're welcome.
Adding a Dynamic DNS into the mix can make it a little more complicated, but the core concepts remain the same. Happy to hear you were able to get it working while having to work with Dynamic DNS and your gateways. I've personally done this setup also with Dynamic DNS, using a DynDNS client running in the network, and it works great. Really like how I can use a domain name instead of a public IP since the ISP in that network setup doesn't guarantee a static IP address.
Pretty good tutorial! Easy to follow! Thumbs up Dev Odyssey! :) :)
Thanks Mr D!
Really appreciate your compliment and continued viewership. It's great to have you coming back and enjoying my videos
😊
helped me integrating my vps into my lan. i found your explainations of the settings and what they do really useful. keep up the good work!
Thanks for watching @syss666! Glad I could help you connect your VPS to your local network, and understand the process / settings at the same time 😊. Looking to make more common use case videos like this!
I was looking for something like this a while ago and came across tailscale. It is doing pretty much the same thing but in a noob friendly way.
Thanks for a great video.
Thanks for watching and for the compliment Hay!
I have heard of tailscale for awhile now. I have yet to play with it but I am a big supporter of how they use Wireguard as their backbone for their VPN tech, and then enabled additional security controls on top of it, like two factor authentication. That's really cool, and something I'd enjoy setting up. In particular, I am a fan of their network topology, and mindset that they really endorse from Wireguard, that being the peer to peer model, as opposed to client / server model. In that, you can create a VPN mesh overlay network, where all devices on tailscale actually belong to their own network. Then additional Layer 2 controls they have on it is pretty neat.
Nonetheless, I am getting into the weeds of it, but tailscale does have an easy way to set this up, and I'm happy that you found them. I'd encourage you to look more into them if you have other devices you want to add to a VPN network.
That's just what I was looking for.
Nice video, Thanks!
Awesome! Happy to hear that Joaquín. Appreciate the compliment 😊
Awesome, easy to follow, thank you so much!
You're welcome @striker_rafael! Thanks for watching. I'm happy to make great content just like this. I have plenty of more video / network ideas I need to get started on that I'd be happy to share.
This is a gem, to find someone who understands this enough to make it simple. Love wireguard, but it does take some practice to get its lesser documented features. (You may find useful an AllowedIPs calculator, which sort of creates DisallowedIPs the long way.)
Thanks for watching @derekteetv!
Your compliment means a lot to me, and glad I was able to deliver on this content in that way. I've definitely had my share of hours of frustration (and learning) so I could finally distill it in this way. I still mess up at times and have to reteach myself, and then it comes back to me.
Allowed IPs is definitely useful to automatically create the routes you need to send traffic over that interface, thats what it really does. If thats unchecked, then you'll have to create those routes yourself. I'm sure there are use cases for that but I haven't encountered it yet in my deployments.
Worked like a charm!
Thanks for watching @R4C3R!
Glad it worked seamlessly 😊
Thanks a lot for your work! Explained step by step for beginners and really easy to understand. Much appreciated! And yes, I would love to know how to make a site to site VPN from a pi OS, as a RPi 4 is all I have at the moment.
You're welcome @luisb9220! Thanks for watching and the compliment, I truly appreciate it.
Great to hear! So you can install OpenWrt on your Raspberry Pi, if you want, or you can simple install WireGuard on your RPi OS, and configure the client in the same manner as I do above. Granted, it will be mostly similar, at least all conceptually, but if you can make a WireGuard configuration file, put it on your RPi 4, and create some firewall rules (I'm assuming Pi OS uses ufw like Ubuntu) for forwarding traffic to the network the Pi sits on, then it should work. If you've configured a WireGuard client on Pi OS before, it should only require a few modifications to get it working as a site to site VPN, notably the routing rules, and firewall rule(s) for forwarding traffic.
Great video! Exactly what I was looking for.
Thanks @henrik2117! Happy to hear that 😊
@@DevOdysseyI really like the way you have made the video with an introduction overview followed by a step by step walk through.
This way I can see what needs to be done and how.
After watching it a couple of times I have noticed things I didn't first and have a better understanding of concepts and configuration and can add my own ideas 😊
@@henrik2117 I'm glad to hear that, thank you 😊. Honestly thats how I have learned a lot of this myself, so I figured why not create my educational content in the same manner. Diagrams and real life, useful demonstrations go well together to really ingrain the learning, not just how it works, but also why it works, and why it's useful.
Repetition surely helps in learning so I understand why you'd need to watch a couple times. Usually I have to stumble through the process the first time around and then repeat the steps in order to really have it sink in. It's like watching a movie the second time around, you always notice something you didn't see the first time.
Definitely add your own ideas, as this is meant to just be the base of what you can do. Using my other videos, you can really start to combine things in such a way that makes your network personal to you and your use cases. It's really a fun process to take these concepts create a network uniquely your own.
Thanks again for your time and effort. As usual nice explanation. Keep it up 👍🏽
You're welcome! Glad you are enjoying my videos and that you're able to follow! I have plenty more videos to get to 🙂
@@DevOdyssey I can’t wait to see your future videos. I am using Pi based OpenWrt router since 2022 February and I am simply amazed by that and not going to go back to any consumer routers. Keep sharing your knowledge.
@@goppinaththurairajah760 Thanks! You have a nice base setup, and given what you can do with an RPi, hardware wise, and OpenWrt, software wise, there's a lot that you can do. Its truly amazing how many things you can do with is, but also amazing how little options you're given from consumer grade hardware and software. They're getting better, but wayy behind what you can do with open source software, on well supported hardware.
Once you start this journey, its just too difficult, even painful to go back to consumer routers! There are some prosumer grade hardware and software that does well, like UniFi, but otherwise, you're not gonna find much else.
I look forward to sharing not only what I know now, but what I learn as I keep finding new hardware and software to play around with 😊
@@DevOdyssey thanks again for your reply. I am using U6 Mesh the Cola can as my access points in conjunction with my Pi. As you mentioned I am amazed by the software that UniFi delivers. I am convinced by the UDR but OpenWrt + Pi gives me more benefits like AdGuard Home with NextDNS, VPN split tunneling as you mentioned in one of your videos and BanIP. Recently I started experimenting Docker on OpenWrt for the missing functions. Keep it up 👍🏽
@@goppinaththurairajah760 you’re welcome! I haven’t used the U6 Mesh, but when you call it the cola can, it seems familiar to me haha. You’re setup is something I’d definitely recommend! OpenWrt handing the routing / firewalling, and mesh access points for the WiFi, as the WiFi on Raspberry Pis is far from ideal to be used as an access point. I prefer UniFi for my wireless access points given their powerful software. It’s nice to get software like Ad Guard, BanIP and NextDNS, that you wouldn’t get with UniFi. Call it a win win situation. I haven’t used Docker in OpenWrt, but I’ve heard of many people using it, and I can see there being a lot of good software you’d want to containerize on a router. I’d be curious to hear how you end up using Docker on OpenWrt.
finally i found what i need easy understand . thank you so much
You're welcome Preechan, thanks for watching.Glad this video was what you needed to understand, and I'd hope, to implement a site to site vpn with Wireguard.
All the best in your networking projects 😊
Really great tutorial. Thanks for that. Quick question. Do I need a dyn DNS on both routers if I want to avoid the keep alive?
Thanks for the compliment @sirlanzi!
Always happy to hear when people get value out of my videos.
As for your question, technically no. DynDNS will not save you from needing the keep alive, you could still well need it with DynDNS.
The reason DynDNS is needed is because of two reasons really. One is your external IP is CGNATed. Meaning you share a public IP address with other people. Because of that, you don't control the public IP address the internet sees, and you can't do port forwarding. The second reasons is you don't control your network, or have access to port forwarding or open up ports on your firewall.
What the keep alive does is make sure one end of the tunnel initiates the connection, and keeps it going, since the opposite end cannot initiate the connection, due to the above reasons. When you get DynDNS, this doesn't remediate CGNAT or lack of network control, it just gives your IP address a DNS record. So if you fall into either situation above, you'll still need the keep alive on one end of the tunnel, particularly on the end that has your CGNAT IP or "IP you can't control". DynDNS is just convenient for the end IP that does change, that you know you'll always be hitting the right endpoint.
@DevOdyssey Thank you for this amazing walkthrough! I got this working in the same conditions shown in the video. I'm wondering if this would work if I have multiple "Site B"s which I'm unable to set static IPs for and are behind ISP-provided routers. I want to build a couple of plug-and-play openwrt raspberries that I can share with my friends out of town so they can access a media server in my home network as if it were in theirs. They don't have to reach each other but Site A must be able to reach both "Site B" networks for serving media. Will it suffice to have only one peer (Site A) in those multiple "Site B"s? I'm also behind an ISP router but I think I can set up something like ddns and port-forward traffic from my ISP router to the raspi. Will this work?
Thanks for watching @milleniuminc!
I really appreciate the compliment. Glad you were able to follow along and get it working!
In regards to your question, yes, you can have "multiple Site B's". While they're referred to as Site to Site, it can really be site to site to site and so on. For where you do not have static IPs, those "sites" will need to use dynamic DNS. Now if these sites don't have public IP addresses you control, then you will need to use persistent keep alive when behind that site.
With regards to when needs to reach where, so long as your "Allowed IPs" in the Site configuration (i.e. Site A as a peer for Site B) are reflective of Site A's IPs, then it should work. In particular, you only really need the IP Address of the media server in that configuration. This would effectively only make it possible for your friends to reach your media server over the site to site VPN. In addition, you'll want to ensure there are no firewall rules blocking the connection, but if they are using consumer grade routers, then there probably aren't.
Keep in mind here that if your friends have the same local IP's you will want them (or yourself) to "Re-IP" their (your) network to a different subnet, so they can reach your media server in "Site A"
In my explanation above, I refer to your home network as Site A, and your friends as Site B, just for clarity. So yes, it would suffice to only have one Site A (as a peer) in those Site B configurations. Even though you are behind an ISP router, so long as you can port forward and do dynamic DNS, as you stated, you should be able to get it working, where your friends can reach your media server, but not necessarily each other.
Dev Odyssey
Great idea as I want to allow my family to use my network printer from their home as their printers seem to refuse to work with Windows 10/11 and or Linux another point is for my digital safety I would like also when public WiFi use Wireguard vpn to my home network via a wireless RPi3B+ OpenWRT the problem being is my ISP router doesn't do routing tables and obtaining a A/VDSL modem to build my own router is prohibitively expensive. I suppose I could use the DMZ on the ISP router for just the modem and use a RPI4 for my router and do the same at my family's home.
Another idea for the family and myself is to save my work to part of a HD at theirs and they do the same with their work here, of course encrypted on both sides using wireguard and PIs sort of a cloud storage for the cost of the PI, HD and running costs. Yes I am sure commercial systems are available being a bit of a nerd anyway and with self sufficiency attitude home brew is preferred.
Any ideas or comments favourable or not are welcome.
TIA
Thanks for watching @paulmassey7596! Those are great use cases for implementing a site to site VPN. I'm not quite sure how well a network print will work, assuming they're not programmed to only work on Layer 2 network, but only testing it will determine if thats true. Depends on the printer really, as more commercial solutions definitely dont have that issue. Though, if anyone wants to pick up a printer item, they'd have to stop by your place to pick it up.
As for your networking concerns, do you have the option to provide your own cable modem? I'm not certain how you get your internet (Cable, DSL, etc), but if you can provide your own, that will enable more flexibility on your end. Since cost is a concern, you might have to save up for a good modem if you can provide your own.
If your ISP router has bridge mode, that should let you use a Raspberry Pi as your router, though you'll need a switch and and access point and VLANs (if you plan to only use the onboard RPi4 NIC, and no USB NICs). I'm actually working on a video that goes over a configuration like this. To this end, it would require more spend, so it might not be the option you want.
Better, you can try to use your RPi 4 as the gateway, DHCP and DNS server, where it basically replaces your router, but without having to change the physical setup (just logical). The router still acts as the upstream gateway (and firewall), but you can get the benefits of OpenWrt on your network.
Lots of options and things to consider, but its definitely doable without needing excess equipment. Just depends on how you want to set up your network and what you want to optimize for.
i wish they build 10 thumps, easy tuto ever. thx.
Thanks Freeman Gordon! Appreciate the viewership and compliment 😊
Thanks for the video. All good except if we need to get full functionality, i mean to get connections to all the devices on both sites will need to add firewall forwarding on VPN zone to allow traffic to LAN on both sites A and B.
Thanks for watching @customautomation3230! I appreciate the feedback.
So initially when I made this video, I set up the zone forwarding rules between the LAN site A and LAN site B via the VPN. So both LANs should have full access to each other in this set up. The zone forwarding from the VPN to the WAN is for VPN devices to access the outbound internet via site A or site B router(s). The one thats missing, VPN to LAN zone forwarding, would allow traffic from VPN connected devices, to LAN devices, on either site.
I was initially focused on getting the LAN traffic between the sites working, but for anyone who wants their VPN connected devices to access LAN devices, then you certainly want this rule, so I thank you for mentioning it for anyone who's encountered that use case and is looking for a solution. Though I will say at this point, if you have two zone forwarding rules between each other, then you might as well get rid of the VPN zone and keep everything all on the LAN zone, then this way, you don't even need to write the zone forwarding rules at all.
Thanks for the video @@DevOdyssey
I almost get everything working but I can't get a client from site_A to ping a client from site_B.
"both LANs should have full access to each other" is different from "VPN connected devices to access LAN devices"?
I'm a bit confused here.
@@arthur_vertrouge you’re welcome, thanks for watching!
First, can you ping a client in site A from site B? This would at least indicate to me if the issue is one way, or both ways, and if your config was correct in one direction.
Anyway, pings can be misleading, because the end devices you are testing with has to be set to respond to pings, that might not always be the case, so first you want to check that, let alone respond to pings from devices outside its network, since that’s something I’ve encountered as well. Once you confirm that, then you can try your test again or use a different means to test like https or whatever your end test device responds to.
While those statements differ, the way this setup was done both should be possible, in this video, the VPN basically acts as a sort of network bridge, connecting the two networks together. With the appropriate routing rules, the LAN on either side should be able to communicate to the LAN on the other side via this bridge. The VPN connected devices should also be able to access the LAN, again because the routing rules enable the VPN devices to reach the LAN networks, on either side. The routers are technically VPN devices, just have an interface that’s on the VPN, that enables this bridge to begin with, and they should be able to communicate in both directions. Usually it’s easier to visualize this but sadly there’s not much I can do within a comment, the video diagram is your best bet at understanding.
Nonetheless, when you have issues here, and the VPN is confirmed to be working (i.e handshakes), the issues usually is routing rules, or endpoint devices not responding to certain traffic or source IPs. If you can share more about your situation, I can offer a bit more of an explanation.
thank you @@DevOdyssey
I get it working by putting tne vpn in the lan zone.
I imagine it was a firewall rule.
I don't understand why using your conf, ( or what I implemented as being your conf) I can't ping a client A from A client B. But as it is working I will pursue my journey.
Thank you for your work
@@arthur_vertrouge You're welcome! I'm glad you were able to get it working. If the zone are not done right, they can restrict access by prohibiting traffic forwarding between different zones. Let alone this gets difficult to troubleshoot often in OpenWrt because logging is not always the easiest to get a hold of, as not all traffic / activity is logged.
I'm not sure what it was either, since it worked for me. I will say I did have some ping troubles even with my configuration. However I determined that to be an endpoint problem, as some of my endpoint's were set up to drop pings, and never respond. But I knew traffic was flowing properly as I would get pings back for a different devices on the other LAN.
Nonetheless, awesome to hear you got it working and appreciate the recognition 😊, this is work I have fun doing.
Hey @DevOdyssey. I've used your video to create my own site-to-site and it works! However, now I'm struggling to initiate a connection between my macbook using the wireguard app and my wireguard interface on my OWRT router for when I'm away from home. I set up a new WG instance on my Site A, but translating your Site B instructions to the wireguard MacOS app is proving challenging. I thought I had this going but my OWRT WG interface isn't showing any handshakes despite my macbook saying a connection is active. Do you have any suggestions? I'm guessing I'm missing something simple.
Thanks for watching @liammiller9015!
Glad my video helped with your own site to site vpn setup! So it seems like you’re having issues with the new interface you set up. So to note, you don’t necessarily need a new interface. You can use the existing interface that you created for the site to site vpn and simply add the macOS WireGuard peer to the configuration file. That should do it, unless you want to segment the macOS client for some reason.
Troubleshooting WireGuard can be challenging since you don’t see what’s necessarily going wrong in the process. Using site b instructions to set up the client isn’t exactly what you’d want to do, since all you want is a client and rather you don’t want your macOS client to act as it’s own “site”. I’d suggest following my video where you configure WireGuard on a OpenWrt router, since in that scenario it’s acting as a client.
th-cam.com/video/04q41GEPvKA/w-d-xo.html
I’d also try to use the existing WireGuard interface on the router for Site A and add your macOS client as a peer instead of making a new one, unless you have a specific reason to do that. It might be easier that way but it should work with a new interface nonetheless.
great video, man. thanks for directing me to this from your other VPN setup video. I think the only thing left for me to figure out is how to use this setup to browse the external internet from one of the "sites" you have set up. Is that already working with this setup?
You're welcome @ThePwig! Thanks for watching.
In this setup, it does not browse the external internet from one of the sites, since this is more focused on browsing each other's internal networks for the opposite route.
The only thing you will need to do to browse the internet from one of your sites is the following. When configuring the peer (ex: at 13:44), in your Allowed IPs section, you add 0 . 0 . 0 . 0 and : : 0 / 0 (without the spaces between the periods, semicolons, and forward slash).
This tells the router to route all IP addresses, IPv4 and IPv6, all through the Wireguard tunnel, and therefore should be able to browse the external internet via the router's internet connection.
Thanks for the walkthrough. I got both sites going with little trouble. I want to send site B internet traffic through site A's public internet connection. I'm sure it's possible with this setup just need some additional steps. I've monkeyed around with it and have not made the correct setup yet. Can you point me in the right direction? Thank you for your time
Thanks for watching Premier Backyard Buildings! Sorry for the bit of trouble but glad you got it working overall. Always a bit of trial and error in the process.
So if you want to send site B internet traffic via site A's public internet connection, all you should need to do is add the following "AllowedIPs" in the site A peer configuration on site B's Wireguard interface (refer to 13:52 in the video)
0.0.0.0/0 (for IPv4)
::0/0 (IPv6, if you have any IPv6 devices in your network).
That should create the static route that tells Site B router, to route all traffic through the VPN configuration, and the out the WAN of Site A, since you already forward the VPN zone to the WAN zone (as done at 9:45 in the video)
@@DevOdyssey Dang simple... sure thought I'd needed more than that. Thank You for help.
@@Wakkowillie Nope, just a routing rule to tell all your traffic where to go. Happy to help!
Have you tried routing ipv6 over wireguard? I'd like to enable that to have a different, more open, set of firewaill rules between sites. They both have public v6 space, but generally firewalling off incoming traffic.
Thanks for watching Tim!
It’s funny you just asked this, as on my VPN on a router video using wireguard, someone asked a very similar question.
I have not tried this, as I have yet to tackle IPv6 as a whole. I disable it in general since I’m not using it, for security reasons. But, I do want to pursue it as I get a deeper understanding of it.
So enabling it over wireguard should be fairly straight forward. Just make sure to create an IPv6 IP for the VPN range on both wg interfaces on both routers. Then, for route allowed IPs, write in the IPv6 ranges you want over the wireguard tunnel.
Then, you should be able to create IPv6 firewall rules for the new IPv6 network you created and assigned to the VPN zone.
Let me know if you try this out. I’m curious to see how it works for you.
Great tutorial. How would I set the WG VPN to one LAN port on my client router?
Thanks for watching Liam! It looks like you found my other video that I would've referenced here to help you with this (the Policy Based Routing video) so I'll continue my response there since its more relevant.
Hi! Thnx for the step-by-step. I know my question is very noob but how does one configure an OpenWRT router to "simulate" WAN/Internet?
You're welcome, thanks for watching mkersevan!
No worries. In general sense, the reason why I describe this router to simulate the "WAN / Internet" is because I set up a couple of VLANs on it with two distinct networks that used public IP ranges. As for the zones, I used the WAN zone available by default in OpenWrt. The biggest takeaway here is that I am using public IP ranges. There's nothing to prevent me from doing that, but if I hooked up that router to the internet, there would be IP collisions and I wouldn't be able to visit the real endpoints behind those real IPs on the internet.
But thats really all I did.
Hi, thank you for the video, one question, is it possible to set this config to site a device with Owrt and use a frtzbox on site_B?
Thanks for watching Gugu!
While I’m not that familiar with frtzbox, I am aware it’s a common router used for OpenWrt.
Unless there is something specific about this device that I don’t know about, there should be no reason why you can’t apply the config in site B, or let alone site A, on your device. These configs effectively mirror each other, taking into account the networks in the different routers / sites. So both should work fine and I can’t imagine any issues you would have using plain OpenWrt.
I did just read more into your question, and realized I missed something. Since I have never used frtzbox, I’m assuming you do not have OpenWrt in that box and instead have the manufacture’s firmware. Given that, I’m not sure how possible this config would be. You might be able to connect to wireguard if they support it. So long as you can route the allowed IPs, this should probably work for frtzbox, but again I can’t be too sure without any person experience with frtzbox firmware.
Thank you for the good and easy to understand video. I managed to setup my site to site wireguard vpn following your guide.
Now I am trying to route all traffic from one particular IP in SITE B to the WAN on SITE A. May I know how to do this?
Thanks for watching @iamasupernoob! I appreciate your kind words.
Glad to hear you got it working using my video! Now to try and route all traffic from one IP in Site B to Site A WAN, you'll need to do something called Split Tunneling or Policy Based Routing. If you watch my video below, it explains how you can do that.
th-cam.com/video/FN2qfxNIs2g/w-d-xo.html
Interesting project and a good tutorial, however tailscale/zeroteir is a lot quicker and easier to set up.
Thanks Alan!
I definitely agree with you there. This setup is a more "in the weeds" if you want to get your hands dirty with direct configuration management of Wireguard, which isn't that complicated. I admire Tailscale, as they do use Wireguard at their core, and have also build many cool features on top of it to make it a enterprise grade turnkey VPN solution, especially where there are features that Wireguard lacks, Tailscale has filled those gaps well.
Personally, Tailscale is on my roadmap to try out someday. I have not heard of ZeroTier but I just looked at it and seems interesting, very similar to what Tailscale does. ZeroTier even has an OpenWrt port which is pretty cool, not to mention Tailscale
github.com/mwarning/zerotier-openwrt
openwrt.org/docs/guide-user/services/vpn/tailscale/start
Thanks for sharing!
Yes and works on CGNAT without any issues
Thanks for the video! How did you configure the Netgear (also running OpenWrt) to simulate the public Internet? I'd like to use that to confirm that the site to site VPN will actually work (with a simple peer IP address change), before I take site_a router out of town to where it'll actually be used.
Site_A: BPI-R3 mini (OpenWrt main snapshot)
Site_B: Ras Pi 4 (OpenWrt 23.05.2)
What I'd be using to simulate the Internet: Netgear WNDR3800 (OpenWrt 23.05, currently on 100% default settings) that I have laying around.
You're welcome @alvallac2171 and thanks for watching!
Great question, and quite simple really. Basically, instead of using RFC1918 address in that router, I used non RFC1918 addresses, i.e. public IP addresses. When I created a new network on an interface, I just gave it a random public IP address. Doing this is totally possible, but all it means is that if you're uplinked to the real internet, you're gonna have issues reaching those real endpoints out on the public internet where those IP addresses overlap. There are companies that have implemented non RFC 1918 IP addresses in their network awhile ago, and some even implement their own public range on their internal network for their own reasons.
So since I was doing this in a lab environment, that Netgear router was not uplinked, it was isolated and what I considered my ISP for this video. The Raspberry Pi's were simply getting a public IP from the ISP router.
So give it a shot, should be easy enough to get working, and let me know if it works for you.
Hey, thanks very much for your video, it is helping me a lot! I still have one problem and I am not sure if I have set all things correctly. I have a PC in my site A which needs have remote access to a PC on site B (for exemple via tightVNC). I can ping the PC but in tightVNC the connection is allways being refused. I tried to do port forwading in ports 5800 and 5900 (tightvnc ports) from lan to vpn and vpn to lan, but I sill cant do it. What can I be doing wrong?
Thank you very much!
You're welcome, thanks for watching @alexandrerodrigues7900!
Glad its helped you out. Now for your issue, first of pings between both machines (I assume it works both ways), is good since it would indicate your site to site VPN connection is working well. The way this setup was demonstrated does not take into account any firewall-ing (other than zones), meaning all traffic should be allowed in either direction, this is a default allow (since we are using OpenWrt, not the same for all firewalls).
Given that, your tightVNC application issues are likely related to tightVNC itself. You shouldn't have to do any port forwarding (or even NATing, as not done in the video), because the tunnel will handle connections between the two networks, as if they under the same router, i.e adjacent LANs.
Sadly, these types of issues become hard to troubleshoot with OpenWrt and its lack of robust logging. You can do some logging by editing the zone and checking off a box in the advanced section to enable logging. Then the 'logread -f' command in the terminal can show you if you are getting drops or blocks. But by design, you will not see any accepts. This can be helpful to truly see if drops or blocks are occurring.
With that in mind, you said the connection is being refused. Can you elaborate here? Are you immediately seeing the connection stop, and being told by tightVNC that its being refused? Or are you seeing it simply time out? Those indicate different types of network behavior. A block would stop the connection immediately, meaning there is something in between thats explicitly stopping you, generally a block rule. A timeout could indicate a few things. It could mean that the firewall is dropping traffic because of a rule, or it could mean that the interface is not listening on that port, its more ambiguous.
I would believe you are having drops occur (not blocks), so its something with tightVNC not liking being connected to over the site to site VPN.
Does tightVNC work if you're on the same network? Have you checked your tightVNC settings to allow connections from different networks? I would check there first, and if you are restricted to connecting to tightVNC over the same local network, NATing should address this issue easily.
thanks, great video! Just a question: when one of the sites is behind a mobile network without having public IP (it's just NATed), what IP will you enter in the VPN config?
You’re welcome and thanks @captainofcrunch1978!
So let’s say site A is behind a CGNAT (pseudo public) IP, while site B is not. In site A’s config, when setting up site B as the peer, you will input site B’s IP address as normal, but, you’ll also want to use the persistent keep alive, as I noted in the video.
In site B’s config, where site A is the peer, you will leave the endpoint IP address empty.
This is because you can’t reach the CGNAT IP through the public IP (technically you could but that’s something I plan to talk about in another video, and even so, you wouldn’t want to do it this way unless it’s set up properly and that effort on its own is a lot).
You’ll always rely on site A to initiate the VPN connection and to keep it alive. Otherwise, if site A stops sending keep alive packets, then the tunnel will stop and so does the site to site VPN. This is exactly what that keep alive packet is meant for. Endpoint address isn’t technically required per peer configs, it’s really only required “one way” from one of the peers, if that makes sense.
@@DevOdyssey thanks a lot! This is a very helpful and clear formualted answer! I am sure, this will help a lot other users as well!
@captainofcrunch1978 you’re welcome! Appreciate the positive feedback. I do hope it helps others as well.
Diverging into different scenarios over video would make it endless, so I appreciate having discussions in the comments about tweaks to the configuration to cover specific scenarios.
Hi there, great content. I have a small question related to cgnat and port forwarding. I googled but could not get an answer, hoping to get clarified from you.
My site A is behind a cgnat, hence no port forwarding. But here is where my home server is running. I also have a pfsense instance running in this site.
My site b gets a public ip so I can open ports. This is not a static public ip though, hence I'll have to use a ddns service to figure out the public ip. This site has a openwrt router.
Can I get site to site working with this kind of setup? Just having one site with open ports and a dynamic public ip and the other site behind a cgnat ?
Hoping to get some answers. Thanks!
Thanks for watching Sam!
Glad to help with a CGNAT scenario, as thats a common scenario that hinders VPN server usage in general.
First, using DDNS is definitely a big plus for Site B. Frankly it would be necessary for a consistent VPN connection, so definitely do that. I utilize DDNS for the same reason for my Wireguard site to site VPN.
You definitely can get a site to site working with this setup. This is how you would do it.
Starting with Site A - This needs to be your Wireguard "client" (technically Wireguard is a peer to peer model with no client or server, but that aside). By this, I mean your Site A Wireguard instance needs to be the one initiating the VPN connection. This is specifically because of the CGNAT in that environment. In that setup, you'd create a peer for Site B (in Site A config), and you'd use that domain name of your Site B IP (that you setup with dynamic DNS) as your endpoint host. Then, and very important, you'd set up a Persistent Keepalive with at least a value of 25 (a packet every 25 seconds) to keep the tunnel alive. Then lastly, you'd set the Allowed IPs as the private IP addresses in Site B, or the IPs you want to send over the tunnel). Make sure to check off "Route Allowed IPs" that will automatically create routes for you.
On Site B, you'd setup the peer (Site A), with just the public key of Site A, and the Allowed IP addresses of the networks in Site A, along with checking off "Route Allowed IPs". Here, you do not need a Endpoint host, because Site A is initiating the connection, and Site A is not a static IP you control since its CGNAT. Lastly on Site B, you'd set up port forwarding to allow all IPs to forward to the port that Wireguard is running on in Site B, since again, you don't know what IP the Wireguard connection will originate from.
That should be all there is to it. Once you save it, you should see a handshake and it should start working. The setup in pfSense should be very similar, the UI elements will look different of course, but concepts are exactly the same. Let me know if you get it working!
@@DevOdyssey Thanks much, will try and let you know how it went. Very much appreciated on the level of detail you explained. You'll reach heights as you dreamt of
@@aravind3626 You're welcome, thank you for for the support Glad to help and to provide that level of detail so that you understand what i'm talking about. Best of luck!
EXACTLY what I wanted to accomplish - fantastic video, but, I'm hesitant to do this with my existing WireGuard setup - I have a WG Server in Europe, and I am in the US - - as I currently have it set up, I can only access the Server Network - I'm on GL-Inet devices on both...
I'm afraid of breaking the connection from such distance... and losing access to the server - - but I DO wish to get everything on 1 subnet... Does that make sense? Any advice for my particular situation?
What must I look out for when doing this from 1000s of miles apart?
Thanks for watching @SFLibery!
Happy to hear this is what you're looking for. Now a site to site VPN would be very convenient between US and Europe router placements. At the same time, I can see why you would be hesitant, since if you mess it up, you lose access to it.
In terms of getting these on one subnet, you can have them share in a VPN overlay network, such as in my video here they're both on 10 . 10 . 10 . 0 / 24 network, but then each router has its one LAN of 192 . 168 . 1 . 0 / 24 and 192 . 168 . 2 . 0 / 24, but they're accessible over the VPN Overlay. If you want them to truly be on all one subnet, like 192 . 168 . 1 . 0 / 24, then you'd need to set up a Layer 2 VPN, which is not possible with Wireguard. OpenVPN can do this, in addition to IPSec (L2TP), but thats only really if you need Layer 2 traffic. Wireguard should suffice if you don't, and I find it easier to implement.
Anyway, my suggestion is if you don't want to break your setup, you can do one of two things.
1. Expose SSH publicly over the internet. This is probably one of the easiest ways to ensure you still have access to your router, regardless if the VPN goes down, but you'd want to ensure you have SSH well secured. At the very least, your SSH should only accept Public Key login. You could install fail2ban as well if you want to rate limit SSH brute force attacks as well. Depends on how many layers of security you want. At least here you can SSH into the router and do local forwarding to access LuCi over the tunnel.
2. Set up another Wireguard interface thats simply dedicated to backup access. Here you can create another Wireguard interface, just as you created the first one, but leave it set up that way, so incase you break the first one, you can fall back onto the second interface.
Regardless of what you chose, you should be able to configure the site to site VPN without losing access to it, if you take the proper precautions. Best of luck!
thanks so much for your thoughtful reply - I enjoy your content - best wishes@@DevOdyssey
@@SFLiberty You’re welcome, glad to help. Let me know if you get it working!
Want to see a Site to Site VPN using Raspberry Pi OS, another distro, such as OPNsense or pfSense? How about with OpenVPN?
Yes!!! I've been frustrated trying to set something like this up between my network and my brother's but I don't have access to his router at the moment. I want to do off-site backup for both of us at each other's apartment. Even better because we live in different states!
@@AddieDirectsTV Thanks for watching!
Now this is what I love to hear! this is one of the first stories that I heard and inspired me to get into home labbing / networking. Your family members networks make great use for testing out VPN tunnels, storing offsite data / backups, etc. Its even more fun when you live in different states, like you can be on his network as if you were there with him. When you see you have that ability, and not have to use software from large corporations, it feels very empowering. All the best with your implementation! You'll have plenty of fun with it!
A couple of things were confusing, but I got it figured out. I’m going to put together some slides because of the speed you were doing it at and having to constantly go back and rewatch sections was a bit frustrating. If you want a copy when I’m finished, I can send you one.
@@asbecka Thanks for watching! Sorry to hear about the confusion and frustration, but I'm happy you were able to figure it out, even if it took a few tries to do so. I often speed up the configuration as when recording, its a bit slow, though I know that can be very helpful. I do this so the videos are extremely long. You can slow down the video playback to see more of the configuration at your preferred pace.
I do sincerely appreciate the offer. You can send me a copy to my email in my About section of my channel if you'd like, and I can review it. Nonetheless, I'm glad you were able to get it working!
Hi - Thanks for taking the time to make your OpenWRT Wireguard video.
It really helped me.
I am rebuilding two routers to replace my ageing DDDWRT OpenVPN system which has been working for about 9 years.
I am trying to replace them with two Raspberry Pi CM4s with the DFRobot interface.
Following your video, I have got everything working except I cannot access other computers on the LANs (i.e. computer on LAN A to a computer on LAN B)
I can ping each the router on LAN A address from a computer on LAN B - and visa versa.
Also, I can access Luci web Interface on LAN A from a browser on a computer on LAN B - and visa versa.
But I can't ping a computer on LAN A from a computer on LAN B - and visa versa
You actually show this working in your video.
Have you got any suggestions?
There are loads of cases on the internet where people have had this issue.
I have tried including the local LAN's IP range as "Allowed IPs" in the Peer tab but on a reboot the router becomes unreachable so I have to reflash an image and go back.
Any thoughts?
MIke
I think I've cracked my problem.
I changed Firewall
In the LAN zone, I added vpn to "forward from source zone".
Luci then seems to automatically add vpn to the vpn zone so I let it do it.
After rebooting both ends, it all now works.
Pings to from computers on each LAN
Can also browse to the other LAN's Luci
I also installed nginx on one of the LAN's computers and was able to browse to that computer from the other LAN
So, the 64,000 dollar question is, Have I done anything dangerous?
This is my Luci Firewall - same for both ends
lan => wan and vpn
wan => Reject
vpn => wan and lan
All the best
Mike
@@mikerothery Thanks for watching Mike!
Sounds like you solved your issue. Just to note as well, depending on the system, not everything responds to pings. Notably, many windows systems don't respond to pings by default IIRC. So that can be misleading if your firewall configuration is accurate.
As for your forwarding, that should work fine, and not have done anything dangerous there. You shouldn't need the VPN to WAN / LAN forwarding, because of the tunnel itself, but the VPN to WAN forwarding should allow you to access the internet via the WAN port on the other router its connected to. This video was to just connect the local networks together, but the VPN to WAN forwarding lets you access the other side's internet if that makes sense.
Lastly, I'd make sure the routing rules are set up correctly. I can speak to that because I did this config once, then I missed the routing rules when setting it up again, and it took days to figure it out. Make sure that you are writing the routes correctly, because if not, then you will run into issues with connecting between the LANs. This seems like the problem that you encountered, but its hard to verify.
You can check by running the "routes" command in the terminal. If you dont see a route to the other side's LAN in your routing table, that could be your issue. An example of how to write in the routing rule in the "Allowed IPs" section is as follows for a /24 network. Also make sure you have it set to "Route IPs" by checking off that box
10 . 10 . 10 . 0 /24 (minus the spaces).
Importantly, if you write it as .1 instead of .0 for a /24, the routes aren't actually created, probably because its not exactly correct notation. While it shouldn't necessarily matter because a /24 is a /24, regardless of the last octet, it matters because the route isn't actually made if incorrectly written in the UI, whether it be Allowed IPs or Static Routes.
To recap, your forwarding should be okay. VPN => LAN shouldnt be needed, so you can try testing if that works, after verifying your routes. If not, then put it back. VPN => WAN forwarding should be okay regardless, and lets you access internet from the router on the other side of the connection.
Hope this sheds some light on your issue.
@@DevOdyssey Thank you very much for taking the time to answer my questions and also for posting this video in the first place. I would still be struggling if I hadn't followed your very informative video. Your technique of taking the time to explain the stages is really useful.
BTW, there is no chance of me having any Windows systems causing any issues. I am fully Linux'd - using Manjaro most of the time but Debian based for Raspberry Pi etc.
I did spend a lot of time with the "Allowed IPs" bit (with the "Route IPs checked) but I couldn't reach any device on the distant LAN (I could reach the LAN address of the distant router though). Forwarding though, seemed to fix it but I will experiment more. Checking the route using the CLI as you suggest although I did check the route using Luci. Incidentally, if you add the IP range of the local LAN (/24) the routers will not connect at all!! - This is the beauty of using Raspberry Pis because you can take regular snapshots and revert when this kind of thing happens. On this project I am using Raspberry Pi CM4s and the DFRobot Router mother card. Interestingly, I see that one of your videos is linked on DFRobot's Router's main page.
If you have time, I have another small question. I have been having trouble connecting one of my applications through the tunnel. I use NoMachine remote desktop and it has been a bit intermittent but I am still investigating this - there may be a version incompatibility going on. But the question is - Do I need any Firewall Traffic Rules or should all ports travel through the tunnel?
Finally, I am not expecting any Layer 2 traffic to travel through the tunnel - due to Wireguard only handling Layer 3. Specifically, I would like to use WOL (Wakeup On LAN) to wake computers on the distant LAN. I do this through my existing OpenVPN tunnel and it works really well. Is it possible to route Layer 2 traffic through a Wireguard tunnel. If not, I will probably install a WOL package onto the routers and use a web browser to Luci on the distant end to activate any WOL. But it would be interesting to see if it is possible to run (or implications) of running Layer 2 through the tunnels.
Thanks again
All the best
Mike
PS - sorry for all this woffle!!
@@mikerothery No worries and you're welcome! I'm happy to help, and to share my knowledge and make these videos, it means a lot to hear how much it helped you and how I deliver the content so that its digestable. Helps me get a bit better in what interest me too, keeps life interesting.
Now thats what I love to hear! I'd am mostly Linux'd / Unix'd with a Windows VM in case I need to do Windowsey stuff.
Experimenting away is the best way to learn. Adding it as a /24 should work, so thats strange. Adding it as a range wont work (eg. using a hypen, and not CIDR notation), but sounds like you used a subnet. Its nice RPi's you can make those snapshots, and with OpenWrt you can make config backups, or sometimes I use different SD cards with different configs, and switch them out if I break anything during my testing. I am familiar with the DFRobot IoT board, its a mighty powerful small router board, and great for travel.
So long as you have a working tunnel, you should be okay. So long as you don't have any firewall rules that block the traffic that would be destined through the tunnel, then it should work "out of the box". Unless there are default deny rules, which there should be (unless configured to do so), then it should work. The routing should take care of what destination IPs to send traffic over the tunnel, regardless of the port.
As for Layer 2 traffic, thats a good question. My understanding would match yours, it should only be Layer 3 since thats the layer Wireguard operates on. According to my research, you'd have to tunnel a Layer 2 protocol over the Wireguard tunnel (such as VXLAN), but I can't personally verify that as I haven't tested it. It seems like your second option would be the better bet. It might be worth a shot to try out VXLAN / Layer 2 protocol to see if it works. If so, let me know how it goes!
@@DevOdyssey Just a final update. After getting two Raspberry Pi CM4s with the DFRobot interface working as a "site to site" network, I decided to change tack and bought a couple of those x86 boxes with 5 Ethernet ports, lots of memory and SSDs they weren't much more expensive than doing the job using the RPis. These system seem to be built round the Intel J4125 architecture. Great little boxes. Way more powerful than I need. They are sold as pfSense boxes with pfSense pre installed but I just flashed the x86 version of OpenWRT. These little boxes have HDMI and serial ports so, just like the RPi, you can boot a Live disk with all your favourite utilities - Gparted etc. Anyway, I followed my notes that I made when building the RPi CM4 system (again thanks to your video) and they were very quickly working like the RPi system.
Anyway, I am really pleased with the end result that these little boxes provide - thanks for your help in getting me there.
Above, I mention that over ny LANs, I use WOL (Wake On Lan) which uses Layer 2 protocol so won't cross the Wireguard tunnel. I had a quick look at VXLAN and GRETAP but they seemed to be too complex. All I wanted was to run WOL packets on the remote LAN. So, I simply installed luci-app-wol which also installs etherwake. This generates a Services WakeOnLan menu item in Luci that I can connect to on the remore router using a browser. That in itself solves the problem but I have also written an interactive GUI application that runs on my desktop PCs (Linux of course) that interactively runs an SSH command to the appropriate router and executes etherwake to Wake Up a specific computer on either the local or remote LAN - works a treat - even the wife can run it!!
Thanks again.
Hello, thanks for this great video, I have a question, What to do if one of your routers is behind a nat without a public key? I need to create this type of connection to access a router in another country. thank you
Thanks J T Ochoa!
First, if you don't know the public key of Wireguard interface you are trying to connect to, then there is no way you will be able to establish a handshake with it, from any Wireguard interface. Wireguard uses asymmetric cryptography to establish a handshake, and without that public key, a handshake will never be established.
In addition, if the other interface you are trying to connect to is behind a NAT, then port forwarding will need to be done to connect to the Wireguard server. If you don't have control of the NAT, or are CGNATted, then you will need a cloud server on the internet, who's IP you control, that acts as an intermediary.
If you can't do that, then you can try UDP Hole punching, which still technically requires some cloud server (or STUN service) to broker the connection. Then you can establish a direct connection between the two devices.
But the question you pose seems to state that you have no control over that router in another country. So without that control and public key, theres just simply no way to connect to it.
@@DevOdyssey my apologies, I made a mistake while writing the question, I do control the router at the other end but I don't have a public ip because is behind a nat. thank you
@@usafshorts No worries! So since you do control the other router, you can simply do a google search for your public IP address and you'll find it. Though, to me it sounds like you're behind a Carrier Grade NAT (CGNAT), which you'd have no control over your public IP, and basically makes it useless. So as noted in my last comment, you'd need to do the following.
Your router in another country will basically act as your "client", while your other router that you want to connect to will act as your "server". Lets call these Site B and Site A. For Site B, the router in another country, you'll want to define a peer in that Wireguard configuration as Site A. Then you'd use Site A's public IP Address as the endpoint host. Then set a Persistent Keepalive for 25, and you should always have a VPN connection.
Now if your Site A router (not in different country) is also behind a Carrier Grade NAT, you'll need a cloud server as an intermediary, or you'll need to perform UDP Hole Punching, as I noted earlier. The easiest solution in this scenario is to use a VPN solution called tailscale that uses Wireguard as its core VPN technology. I haven't used it myself but I've heard great things and look forward to trying it out.
Supposing my OpenWRT devices are NOT the DHCP servers. How do I get the correct gateways given to the hosts on each site?
Thanks for watching schematica! Great question.
To be quite honest, I haven't really had experience with this, as any deployment I've done, or worked with, my DHCP servers are always on the routers / firewalls.
So just thinking about it, in this demonstration, I have not enabled any DHCP servers on the Wireguard interfaces on each site, so DHCP doesn't happen there and frankly doesn't apply in this scenario, though I wonder what would happen if you do enable it. Because with Wireguard, you define the IPs in the configuration and is used to establish the tunnel, so it doesn't seem to make sense if it were to be enabled on those interfaces, and you can't even get to the layer 3 networking without first establishing the tunnel, which again required to make the tunnel.
Anyway, for your question, to me, it seems like you'd just tell your DHCP servers what to assign as the gateway when it's handing out IPs. In particular, the gateway would be the site that those DHCP servers are on (for example 192 . 168 . 1 . 1 for site A). Then, via the automatic route creating with the Wireguard interfaces, the gateway would know how to route the packets, if they are destined to the opposite site. So for example you want to reach site B from site A, the device would send packets to site A's gateway first (noted before), and then route it via the Wireguard interface IP (which i guess you could consider as the VPN gateway, in this case, 10 . 10 . 10 . 1 for site A), to reach site B.
So after thinking that out, it shouldn't require any special treatment of the DHCP servers, other than what you normally would configure them as, as dedicated servers not on the router. The routes should handle sending the packets to the right gateway.
How do you tell your company you're working abroad without telling them you're working abroad? Make a series of TH-cam videos about working abroad.
Heh, now wouldn’t that be too obvious? 😂.
“Oh these VPN videos teach others how to make it seem like their laptop is somewhere else? Nah I’m just trying to show people browse the internet securely, I’m not masking my location at all”.
Why would one of the routers be getting the routes and the other one not be getting the routes. On the router at my location I get the route to the other other location, however on the other router it doesn’t show the route. One thing that I did notice was that the other location has pass through set up and my site is just using port forwarding to the inside router from the provider’s equipment. Everything was working wonderfully in the test setup prior to deploying.
Thanks for watching asbecka!
So I'm not 100% sure what you mean by "getting routes", as that happens locally on the router. For example, at 14:08 in the video, this option automatically creates the routes on that server, to send any traffic for those networks, through to tunnel with that peer, in this case, from Site B to Site A. Or, you don't check this option and you manually create the routes in the routing table.
I'm not sure why this would happen, other than a difference overlooked between your test setup and your production deployment. As for pass through, I'm not certain what you mean by that, but at least on one site, the port forwarding should take care of inbound tunnel connections from the other side, for initiating the wireguard tunnel.
Make sure that you have that "Route Allowed IPs" checkbox checked on both router peer setups. If you still are seeing the issue, then create the routes manually in the routing table, and that should fix it.
Is this still plausible if the IP address I received from my ISP is behind CGNAT?
Thanks for watching @CorePeach!
Yes you are still able to. So long as one of the routers / endpoints are not behind CGNAT. If one is behind CGNAT, and the other isn't, you can get this working. If both were behind CGNAT, then you can still do this, but you'd need to use a cloud server / VPS with a IP address you control. Technically, you may not even need a cloud server with two networks behind CGNAT, but this gets a little more complicated and involves something called UDP hole punching. I've tried it out and it works, but its not guaranteed to work with all ISPs. Just a little fun fact.
Anyway, back to the topic at hand. The way you would do this behind CGNAT is by configuring a persistent keep alive on the router that is behind the CGNAT, against the peer that is not behind CGNAT. Effectively, you want to send a keep alive packet from the CGNAT router, to the non CGNAT router, so that you keep the connection alive. You can refer to 15:04 in the video for more explanation.
This video did help a small bit but what I was actually trying to do is gain access to a home server, which i would think is more common to search how to do than basic site to site connection.
Your project likely has at least 1 private ip so you can make that the server (for example, your office), and then anything that connects just communicates with that and endpoint is updated.
For home users, the system is the home server is a client and your device out of the local network is a client as well, to a VPS with a private IP and wireguard running on that. Then route the traffic through the server to the home client and access your home network. There are big differences between this system and the one you have shown. Maybe make a video on that? Very informative otherwise.
Thanks for watching Kyle!
I'm glad it helped you out somewhat. Though it seems like you simply wanted to setup a VPN at home (as a server), so you can VPN into your home network. That certainly is more common that a Site to Site VPN. That is a video I plan on doing, and should be very straight forward, given the last few videos I've done on Wireguard VPNs. I've effectively already covered it here, but the content is not tailored to explain that. In this assumed scenario, its simply VPNing back home, with an ISP that gives you an IP you have full control over (aka no CGNAT).
This type of setup is for connection two networks, so that you dont have to VPN all devices on a network, to connect to another remote network. Its basically a "VPN Bridge".
What you described at the end seems like a scenario where you are bypassing CGNAT due to an IP you don't control. Is that the case? If so, that requires a bit of additional work, given you need a VPS with an IP you control. The timing is odd that you mention this, as I have just completed a setup like that yesterday for another project I am working on, and I plan on a video to demonstrate that configuration as well.
channel ROMNERO
I am having trouble getting this setup correctly.
I am able to get handshaking working.
ping the other openwrt on the other site (site_a and site_b).
But not able to ping any other IP on the other site either direction. What should I check?
Thanks for watching Luis!
First I'm glad you have the handshake working. Your configuration is mostly correct since you can get a handshake.
From what you are describing, it sounds like you check the "Allowed IPs" section under each peer needs to be reviewed. Make sure you have the right IPs here, for networks that are on the *opposite* peer. So for Site A, create a peer called Site B, with Site B networks in Allowed IPs. For Site B, create a Site A peer with Site A networks. Then, make sure that both peers have the "Route Allowed IPs", as that will automatically create the routes needed to move the traffic across the VPN tunnel. If this is not set, you will not be able to ping the other side. This is likely where your issue is. Refer to 14:07 for an example.
It would be excellent if you could emulate this strategy using a pair of Proxmox or LXD containers (or VMs, but not docker). I don't have a pair of Pis or any spare hardware to follow along.
Thanks for watching Mark!
I appreciate the feedback. So you can actually easily do this with Proxmox, LXD containers, or any type of Virtual Machine. I've actually done this myself in my home virtual network, just isn't a full site to site VPN, still using Wireguard. Even right now, I've found a way to virtualize OpenWrt using QEMU on my computer, and I've been using that in preparation for my next video.
The same concepts apply here through and through, regardless if you're using virtual machines or bare metal hardware. All you really need to do is create two virtual machines with Wireguard (or OpenWrt with Wireguard if you need virtual routers), on separate / segmented networks. Then apply the configuration in the same way, and you'll have a site to site VPN. Are you asking about how to set up the virtual machines, on a preferred hypervisor platform?
@@DevOdyssey No, I have a small 3 node Proxmox cluster, so VMs and CTs (lxc containers) are the easy part. Just yesterday I finally got the right combination of manual configs (after a week) to wire together 6 machines, but I didn't realise I could simply connect two subnets with a single "bounce" (?) node in between. I've just now cloned two OpenWrt lxc containers so my next challenge is how to set them up so they emulate your network without the Pi hardware or real world router.
@@MarkConstable Gotcha, thanks for sharing.
I hear you on that, you bang your head against a problem enough and surely the solution eventually reveals itself.
Connecting them all together creates an overlay network, or a Wireguard mesh network, something unique to Wireguard (as opposed to OpenVPN, IPSec, etc). This definitely has its benefits, and Tailscale really capitalizes on it (which is based on Wireguard).
Anyway, to simply connect two subnets, it's just a matter of setting the Allowed IPs in the tunnel / peer configuration, to the destination subnet. Then, Wireguard will create the routes necessary so that it will send the traffic to those destination subnets (so long as you check off the setting in OpenWrt). This is where the "site to site" part comes into play.
I'm not exactly sure how your network topology is (or what WAN networks these OpenWrt containers are connected to), but if they are segmented (aka not on the same Layer 2 network), then you should be good to go. Thats really all I did from the network perspective. The real world router just represents a network connection (over Layer 3), which is easily done virtually.
@@DevOdyssey Indeed, my heads hurts :) I've set up 4 OpenWrt containers, two to emulate your two Pis and another one "attached" by a vmbr0 bridge (ie; your switch) in the same subnet on the LAN side of each Pi. Thanks to your video, it mostly works, and I can ping from the LAN subnet on one Pi to an IP in a different subnet on the other OpenWrt CT (container). What I can't do is ping any other host on either other subnet "attached" to each of the primary OpenWrt containers. The WAN/LAN firewall on OpenWrt may be the problem, so I set up an Ubuntu VM and added a virtual IP on the same subnet as one of the primary CTs and still no go. Again, it might be other issues to do with the vmbr0 bridge not being a real switch etc. I've only recently rediscovered x86 OpenWrt, so I have learnt a lot and will keep hurting my head!
@@MarkConstable My head did too, mostly when I couldn't figure out my problem when I was first getting this set up to work haha.
I'm happy to hear you are most of the way there.
So from the perspective of the OpenWrt containers, do they have separate WAN IP addresses on different LANs? I guess that doesn't necessarily matter so much, but I'm curious.
I''m not exactly sure of what the issue may be, but its good you are troubleshooting and trying to figure it out. So you can confirm there is a wireguard handshake on each OpenWrt container, correct? If so, then also go into the terminal of each container, type the "route" command, and check to see if it looks as you expect it.There should be a routes to the other subnets in the routing table, set up using the wireguard configuration.
Also, make sure those hosts can accepts pings. For example, default Windows instances do not respond to pings, so you'll want to double check a host based firewall, isn't messing you up.
It seems like you're close, so keep trying! Eventually it'll stop hurting and you'll feel great satisfaction once you've figured out the issue 😊
Very good video explanation, the network connected to my two openwrt does not have a public IP, so I set up a vps, and the wireguard service is installed on the vps, and I want the communication between the two routers to pass through this vps. In transit, the IP addresses assigned by vps to the two routers can ping each other, but the intranets between the two routers cannot ping each other. According to the explanation in your video, there is no success. Can two routers without public IPs ping each other's intranet through vps?
Thanks for watching Ge Hou! I appreciate the compliment.
When you say, the network connected to your OpenWrt does not have a public IP, can you be more specific? Are you saying that your WAN connection on your OpenWrt is not from a public IP, but rather a private IP? A little more detail would help in understanding your topology.
As for your question, the answer is yes. If you have two VPN tunnels between the routers (with no public IP), and the VPS, you can route traffic through the VPS and ping the others intranets. This is the topology I assume you are talking about.
router 1 -> VPS (via VPN tunnel)
router 2 -> VPS (via VPN tunnel)
Once you have established a VPN tunnel, your VPS can effectively act a as "router", where you tell it to route incoming traffic through it, to the intranets of the routers, depending on which direction you are going. This is simply a matter of getting the right routing rules in your routing table, and you should have no problem accomplishing that.
I used public IPs in my scenario to simulate each router connected to the internet, and then establishing the tunnel over the WAN connection. However, if you are double NATed (say you have a router behind a router and the WAN connection is assigned a private IP address), this should still work the same way (when establishing a VPN tunnel over that WAN connection).
@@DevOdyssey
thank you for your reply.
No public IP means that the bus line that the operator receives from our community has a public IP, and then the IP assigned to each household is a private IP assigned from this general router.
You mean, if the intranet between the two routers can ping each other, it is necessary to make a routing table on the VPS?
@@gehou6840 Thanks for clearing that up. So just as I suspected, you are in a double NATed environment, which is no problem at all.
So, the point of the site to site VPN is to connect two intranets or LANs. Normally, in an environment with private networks on two different routers, you can't access the the other intranet / LAN, because its behind a firewall (router). If you control the router's public interface, you can write a port forward rule to allow traffic in from another IP, and hence, create the site to site VPN.
In your scenario, it doesn't sound like you can do that for either router. Because of that, you need a VPS, because you need some point that you can control incoming traffic. In a double NAT scenario (or CGNAT), you can't control incoming traffic, because you cannot control the incoming traffic on the public interface.
So with the VPS, you create two VPN tunnels, one from router A -> VPS, another from router B -> VPS. But just because you do that, it doesn't mean that router A can talk to router B right away. Thats because you need to tell the VPS, where to send traffic from router A (to router B), and where to send traffic from router B (to router A). This is done by the routing table. Also in your wireguard interface on your VPS, you will need to ensure that you have two peers, one for router A and the other for router B.
So, on the VPN (wireguard) interface on the VPS, in the Allowed IPs section, you put in the networks from router A, and router B, and you check off "Route Allowed IPs". You do this, just as you do for the VPN interfaces on router A and router B (as shown in the video). This will then allow traffic to the traverse the VPS and go between the routers.
In addition, it order to keep the VPN connection alive, you'll want to set a persistent keep alive. This is one of those scenarios where you would do this. You'll want to use the persistent keep alive on both VPN (wireguard) interfaces on each router, A and B.
I hope that clears it up for you.
And how to do it when I have and would like to have access to 2 subnets on both sides?
1) TL-MR3020 + E398 modem (no public IP)
2) TL-WDR4300 + public IP
Thanks for watching Arkadiusz, and for being a subscriber!
So in this scenario, you would do the following:
On router 1, you would set up a Wireguard interface, and then you would set up the peer as the wireguard interface on the router 2. You would also set a persistent keep alive on this interface (since this is a CGNATed / double NATed network. Then in your Allowed IPs, you set up both subnets (on router 2), and check off, "Route Allowed IPs." This interface effectively acts as a client.
On router 2, you would set up a Wireguard interface, and then you would set up the peer as the wireguard interface on router 1. In particular here, you only need the public key of wireguard interface of router one (you do not need the endpoint host, that's because this interface is acting as a server). You do not need a persistent keep alive here (it wouldn't work anyway). Then you're allowed IPs, you would set up both subnets (from router 1) and check off "Route Allowed IPs". In addition, you would set up a port forward rule here (as done in the video) to send traffic to the wireguard port and on the listening IP.
And that should cover what you need to do. The video should cover everything, minus any specific exceptions I mentioned here.
Can I do it in bridge mode using my internet router ?
Thanks for watching Nicola!
That setting should be irrelevant in this setup. If you have your internet router in bridge mode, then you’ll need another device connected to it that will be acting as a router. Then on that router, you should be able to configure this site to site VPN no problem, assuming you are following along and using OpenWrt and Wireguard.
how is wireguard performance? how does it compare to other vpn options
Thanks for watching @guocity!
WireGuard performance is generally very good. Compared to other protocols, it experiences the least loss in bandwidth. I'm not exactly sure what the percentage is, but if you're curious I recommend reading the white paper.
www.wireguard.com/papers/wireguard.pdf
While I haven't put all VPN protocols to the test, to my understanding its the fastest to date. I personally like it not only for its speed, but simplicity and modern encryption protocols. Since it focuses on only being a secure tunnel and nothing else, it makes it extremely performant.
I'd recommend it as a general purpose VPN.
Sub'd cause of this vid! So I want to use this in my setup I guess 😜. --> At first I had 1 ASUSTOR NAS and used 1 Rpi with PiHole and PiVPN (WireGuard) for accessing it outside my Unifi network. I have bought another ASUSTOR NAS that I will place with my sister for redundancy/backup (she lives in a different city). But now I want to backup my NAS over the internet to the NAS at my sister's home. So I guess this site to site VPN is the trick??? But how do I "add" this function to my excisting VPN setup? Or do I have to create a new one? Or install a new Pi at home and one at my sister? Greetings from Belgium (Flemisch part, so Dutch speaking... 😜)
Thanks for watching @ASUSfreak!
Happy to have another subscriber! I appreciate you sharing your setup as well, as thats gives me some context to confirm that yes, with a site to site VPN setup, you can sync your ASUSTOR NAS, with your backup ASUSTOR NAS at your sister's for redundancy / backup. You should be able to configure that PiHole VPN as a site to site VPN to another PiHole VPN at your sisters, both running Wireguard. It goes without say, but you don't need OpenWrt to do this site to site setup, I just did it this way as its cleaner for me, but as long as you have wireguard running on two devices in two separate networks, its possible.
To add this functionality to your setup, you'd have to do a couple things, that I'll mention at a high level.
1. Modify your Wireguard configuration file, i.e wg.conf, and peers for each of your endpoints (your sisters PiPVPN on your network, and your PiVPN on your sister's network). Technically you'd only need one depending on your setup, but in following this video, you'd make a peer on both ends. In addition, in this config, you'd set up the allowed IPs over the tunnel, basically those being your sisters network range on your end, and your network range on your sister's end.
2. Port forward the incoming port and wireguard connection from your router, to your PiVPNs on each network. Here, you will need at least 1 IP address you fully control, not a CGNAT IP. Again, this is based on the configuration in this video.
Once you've done those two things correctly, you basically have a site to site VPN setup. Looks like this video below should help you get into the weeds of the right details to get it working.
th-cam.com/video/yc9PEM1ovg0/w-d-xo.html
Greetings from the US! I know someone who was born in the Flemish part of Belgium, but ended up learning French instead of Dutch, and she's still fluent in it to this day.
Good luck on your setup!
@@DevOdyssey thx for the vid, I'll have a look later. Yes we have 3 languages over here, cause it's such a big country 🙃. We had to learn French on school from age of... 11 or 12 I guess... (43 now so looong time ago lol). And depending where you work, might need to talk other language. Ofcourse it wouldn't be Belgium as some of us refuses to do that ehahaha...
@@ASUSfreak you’re welcome! I think it’s awesome to learn multiple languages growing up. I grew up bi lingual and picked up Spanish in high school, at least enough conversation to mostly get me by. Now if I had to use Spanish for work, I probably wouldn’t be able to do it haha. You’d have the same problem here with people refusing to speak another language 😂
Why is there a USB device on site A network, but not on site B
config device
option name 'br-lan'
option type 'bridge'
list ports 'usb0'
Thanks for watching @Rugbyu17-jh8qg!
Is the snippet you shared your config? It seems like so (as I don't see it in my video).
What equipment are you running OpenWrt on for each site? to me it looks like your ethernet interface is actually USB based, and its using a USB adapter for that ethernet interface (built in to the board going over the USB controller, or simply an adapter plugged into the USB port).
Looks like they would be different equipment too since it sounds like they aren't the same.
Can you set this up by VirtualBox?
Thanks for watching Muriz!
Yep you can definitely do this set up with virtual box, using two virtual OpenWrt routers, or one virtual router, and another one on bare metal. The same concepts should apply. Is there a specific scenario that you're trying out with a virtual OpenWrt router?
@@DevOdyssey What I am trying to do is to set it up on virtualbox for testing, see if I could configure it the way I need it and buy another cheap TP link router that supports OPNWRT so I could make like a replacement for pfsense.
Meaning if I get OPNWRT firmware in a router I could setup wireguard just like this that second router will serve me like a firewall.
In other words I am getting into networking field. I am taking Pfsense class to get certified. I want to test all scenarios and set up different ways. I have an old 5th gen I5 Laptop the screen cracked so I took the screen off so now I want to setup pfsense with using opnwrt in it I would do vlans since I have one ethernet port on the laptop.
You very welcome. Your videos very well just If you could slow just a little so that people could capture all the steps.
@@Muriz26 Ah I understand. Thanks for sharing. You can certainly do this with virtual box for testing, and I'd recommend it. However, you will just have to be mindful that your system is virtualized and that your networking may be NATed, depending on how you set up your virtual machine. Otherwise, it should mostly be a 1 to 1 setup between your virtual machine, and TP Link router.
This link should help you find a TP-Link router compatible with OpenWrt.
openwrt.org/toh/start?dataflt%5BBrand*%7E%5D=TP-Link
From the sound of it, you should have enough hardware power to run a pfsense and openwrt router on your scrapped laptop for testing purposes.
Thanks! I'm glad to see its helpful. I do appreciate the feedback, and will keep that in mind for my future videos. I generally do this to keep the videos an appropriate length, and not too long. But I'm willing to play around with that idea and let them go longer. In the mean time, you can slow down the video to help you see the steps more easily after I speak about them. I would like to create articles that accompany these videos so people can refer to the steps listed out, but as of now it takes quite a bit of time for me to complete that.
Best of luck on your certification! These certs really immerse you in the product(s), but also really improve your core networking knowledge. Make sure to have fun with it all too 😊
@@DevOdyssey Thank you for all. Virtualbox could also serve as a separate router for one device. I could bring Windows 7 alive with pfsense and opnwrt as a different subnet if I am correct?
@@Muriz26 You're welcome. It definitely can, for a virtual network. You can create a Windows 7 virtual machine, and network it with pfSense or OpenWrt within one of the subnets you define on either of those virtual routers. I have more experience with virtual networking with VMware ESXi, so I'm not sure about how to create and attach virtual interfaces with VirtualBox, but it looks like it can be done. I found an article that might be helpful for you.
www.brianlinkletter.com/2016/07/how-to-use-virtualbox-to-emulate-a-network/
Thank you for this but I hope you consider remaking this tutorial as it seems OpenWRT/WG have been updated. For example @ 24:48, I have Private and Public keys but on your devices, it's just Private. There are a few other oddities as well. I'm using an rpi 5 which forces me to use a snapshot. I've followed these instructions as best I can but can't get wireguard to work for me. I'm trying to set up a roadwarrior setup where I have a Debian LXC with Nyr's wireguard-install script and my rpi will roam and join various networks via Ethernet/WiFi.
You’re welcome @m23605, appreciate you watching and the feedback. Sure OpenWrt / LuCI will go through UI changes, but it shouldn’t change the overall concepts used in this video. For your private / public key remark, you really only need the private key, because the public key can be derived from the private key. So you don’t need a place to put the public key, it will be “extracted” from the private key.
In addition, RPi 5 is not yet supported by OpenWrt, to my knowledge, and the build you’re likely using is one created by someone in the community, so there may be some things that might not work to your expectations, though I’d really imagine it should work mostly no problem.
Since you want a road warrior setup, you don’t really need to follow the whole video, just need to follow the setup for one site.
Anyway I’m also not sure what script you’re referring to, and what your intent is. Are you trying to make the RPi 5 w/ OpenWrt act as the road warrior client joining different VPN endpoints or the server? Sounds like you want it to be the client, that’s should be trivial, and you can follow my VPN on a router video in that case, linked below. I assume you also are using wireguard on OpenWrt and not within the container itself. If so, that would be different, but the same concepts remain, just that all your config would be via a conf file.
th-cam.com/video/04q41GEPvKA/w-d-xo.html
@@DevOdyssey Thanks for your help. RPi will indeed be the client/roaming router. The lan devices on the RPi should always route via the wireguard tunnel and must never connect via the local wan. For now, it seems to be the best value general purpose computer with USB C power plug which means I can attach it to ta power bank and work on a bus via a hotspot. The RPi 5 seems to work fine with the snapshot from the firmware selector and I'm pretty sure I've messed something up in the configs.
The road warrior setup is tripping me up due to needing it to work behind a NAT/PAT (like in a hotel or any other public WiFi). No idea how I'm going to deal with captive portals. I'm going through various guides on OpenWRT but they are either outdated, confusing or flat out wrong. I'm getting help from the forum but a lot of the time, they just point out things that are wrong (which are in the guides) or just tell me to use another guide and rinse and repeat...
At home, I want to use used x86 thin clients (more powerful and cheaper than RPi as I don't need the GPIO stuff). I've tried just Linux with wg installation scripts but the route configs just get forgotten on restart. I'm currently struggling and failing miserably with OPNsense at home as the wireguard server
@@m23605 You're welcome. Appreciate your additional context as well.
Given what you've said, your use case makes sense and what I suspected it was all along. With that, following the video I linked in my prior comment should be exactly what you want. Its basically a road warrior set up on your router (regardless if you're taking your router on the road or not).
Yea so honestly, I'm not 100% sure how you will work with captive portals, but I feel like you can already accomplish this in OpenWrt somehow. Often times, you will find that information does age a bit, and the Wiki is not always up to date. I've experienced a similar process for myself, and find that I have to try multiple solutions, or a combination, to get it working as intended, especially as versions change. The concepts should stay the same, but how you go about it is likely to vary. I wish I could help more on the captive portal side of things. I haven't tried that out myself, but if I get the chance to, I have a place I can test with captive portal so I'd hope to get it working. I'd probably want to use it this way eventually too.
Thats a fair point on x86 thin clients, I think they are a great solution and do offer a bit more flexibility in terms of software, since not everything has been, or might ever been, ported to arm. You're route configs should not get forgotten on restart for Linux, or any other platform. So long as the WireGuard instance is registered as a system service, it should restart the instance and add the routes to the route table as well. Your issue here seems to be that WireGuard might not be starting on reboot.
Sorry to hear about your trouble with OPNsense, I have good amount of experience here with WireGuard and OPNsense (frankly with WireGuard on many platforms), so if you care to share what's going wrong there, I can try and help. The concepts should be the same, but the UI will be different and the way you go about it. There are small gotchas that sometimes take awhile to figure out. I'd make sure that your WireGuard peer (i.e. your RPi 5), is not only added to the configs on OPNsense, but also enabled as a peer for your wg instance in your configs. I've often forgotten to enable it and end up finding I missed that step. Simply adding it doesn't necessarily enable it for your interface, or more accurately, add that peer config to your instance.
@@DevOdyssey Hey thanks for that. I'll try and post my issues here once I get a chance to play with my lab. In my latest setup, I manged to get handshakes but I think I set my fw rules incorrectly. I'm getting used to it slowly. In your OPNSense video, you mentioned that BSD doesn't have the concept of zones which made things click for me (i.e., OPNSense and OpenWRT both are firewalls but the underlying technology and concepts are different).
Regarding the settings being forgotten, I should have said that it was to do with routing rules and not necessarily wg itself.
Regarding captive portal, I get what you mean. You can't just start recording yourself in a cafe somewhere. I think OPNSense has the ability to create captive portals so you could maybe simulate it in your lab.
@@m23605 You're welcome, and sounds good. I'll help how I can.
I'm happy things are starting to click for you. It took me a little bit of time to get the concepts of zones since I actually started really getting into firewalls with OPNsense, before I explored more firewall capabilities in OpenWrt. Zones can be very powerful when used correctly, but also can get in the way if you aren't sure how to use them.
I do understand what you meant with the routing rules and WireGuard. I mentioned WireGuard because in the implementations I've seen, OPNsense, OpenWrt / Linux, and macOS (haven't tried Windows yet actually), it has the ability to create routing rules when standing up the interface, and remove those routing rules when turning it down. So if there are routing rules issues, it might be that WireGuard isn't making them. It's possible to disable this in OpenWrt, and OPNsense I think, but anyway, on start up, WireGuard should handle the routing unless this has been explicitly been turned off.
If I get a change to try this out in my lab network, I'll give it a shot. OPNsense does have the ability to do captive portal, I'd just have to spend the time figuring it out and then I'll know how it work (both OPNsense and when connecting to it via OpenWrt).
There is no need to hide MAC addresses.
Thanks for watching Frank! I appreciate your continued viewership!
As for hiding the MAC addresses, the reason why I have done that is because I may use these devices in the future for other projects that would be in "production", but more specifically, these interfaces could possible be used as a public (WAN) interface. As a result, the MAC address would be seen publicly by whatever ISP I use. Or if I'm on a public hotspot, those MAC addresses could be collected by other devices on the network. To that effect, they could be tracked. While this is unlikely, it's still possible.
In addition, for WiFi MAC address, or BSSID, I saw an interesting article regarding security research and how BSSIDs were being used to geographically tag WiFi hotspots, effectively revealing a physical location. I can't seem to find the article at the moment, but MAC addresses really only stay private when they are within your own private network, or LAN. Any interface exposed on the outside, in a public scenario, or WiFi, are exposed.
But, you got me thinking, and since I can spoof MAC addresses, it would be much easier to do that to obfuscate the real hardware MAC, as opposed to doing all the work to blur them out. So thanks for sharing your thoughts, as now I have a better idea of dealing with MAC addresses going forward.
pretty cool, but unpractical, as 99.95% of the people won't be using this Luci panel, but more common services like Docker, for example. Thank you!
Thanks for your honest feedback Rafael!
Would you care to elaborate? There are plenty of users that do use OpenWrt with LuCI, as it’s their primary router / gateway to the internet. Though, all this configuration is possible without LuCI and can be done in the terminal / config files.
I’m curious to hear about the common services that use OpenWrt headless, as docker containers (though you could also install LuCI there). What’s the purpose of these OpenWrt Docker containers or other common services that do not use LuCI?
@@DevOdyssey Hi, thanks for the reply =)
Sorry, when I said about docker+wireguard I didnt meant to use it together with OpenWrt at all but only Wireguard + Docker, like creating an LXC Container with Promox, installing WireGuard into the container (with or without Docker) and by doing this and with the proper configuration (I think that it requires IPTables rules) to give access to the LAN network to anyone connected to the WireGuard externally, imagine you accessing your Samba NAS externally (with a cell phone?) by using WireGuard (Site to Site). Thanks!!!
I was just reading about Tailscale and it looks be built exactly to solve the problem that I just described above, I will give it a try. but I don't really like to depend on a private company that could change their Free plan capacity from time to time, I noticed that their free plan sometime ago supported up to 100 devices and now it is 20, maybe they change it to 5 soon? I don't really like this instability, many thanks!!!
@@rafaelcapucho You're welcome!
That makes much more sense, now I understand what you mean. I am familiar with what you are referring to, and it should be roughly transferable in terms of setting up a plain Wireguard configuration. I believe that there is this config sitting in OpenWrt, as uci is just an interface over setting up the raw Wireguard configuration.
Nonetheless, these concepts apply from a holistic level, so if a user knows the Wireguard syntax a bit, this can apply. To your point, on a Linux system, you would use some iptables and ipv4 forwarding settings to set up the site to site vpn. I do have personal experience with this as I have done it outside of Wireguard in Linux (Ubuntu), so I would consider making a separate video that goes more in depth. I was able to learn this as there are lots of good articles out there that show it, but maybe a video is worth "a thousand pictures". Or if I don't make another video, I can share a github gist on how to do it with plain Wireguard config and any additional Linux OS config.
Now with regard to tailscale, I have yet to use it, but it is based on Wireguard, and I recommend trying it out, as I've only heard great things from user experience of tailscale. You definitely don't need tailscale to do that, but if you prefer to use their software and cloud environments, by all means give it a go. Wow, I didn't realize they reduced their free tier capacity from 100 to 20 devices. Thats the annoying part of paid software sadly, it can be very unstable in terms of "product and price tiering", so with that, it seems like a raw config would be best for your use case.
We can continue our discussion if you want to get the right config working for you without using tailscale. But if you want some general guidance as of now, I'd refer you to the following articles.
www.stavros.io/posts/how-to-configure-wireguard/
staaldraad.github.io/2017/04/17/nat-to-nat-with-wireguard/
Let me know if this helps and if you'd like to continue the conversation.
Possible with Socks5? My isp blocking others protocol
Thanks for watching Sadiqur!
Technically speaking, and to my knowledge, a site to site VPN isn't possible via a sock5 proxy. However, you can do a bit of magic with OpenWrt and SOCKS5 to get something close.
You can use packages like sockisfy or shadowsocks to create SOCKS tunnels. I am not sure if this would be system wide, but I don't believe it would be.
You can also create a SSH on OpenWrt by running an SSH command in an OpenWrt terminal, and using the -D flag and a port number, that will open up a port on OpenWrt that you can use to tunnel traffic through, with a SOCK5 client. There are a few ways you can do this. You can refer to my proxy video below, or an OpenWrt forum post as well.
th-cam.com/video/g2iSPBmRZ7M/w-d-xo.html
forum.openwrt.org/t/openwrt-router-as-a-socks5-proxy-for-someone-at-a-particular-public-ip-address/128575
Either way, this should accomplish tunneling your traffic through a server of your choice, but not a site to site VPN.