Can someone please help me with my wireguard config?
I would like to create a wireguard tunnel between the router A and B below:
Clients A = 10.0.0.5-10.0.0.33
with Router 10.0.0.1
with DNS 10.0.0.1 & 192.168.100.1
Router A OpenWrt with wireguard install
= LAN 10.0.0.1
with WAN 192.168.100.10
Getaway A Huawei GPON = 192.168.100.1
with dynamic IP on WAN from ISP
with NoIP DNS my-BASE-domain.com
Getaway B Huawei 4G/LTE = 22.214.171.124
with dynamic IP on WAN from ISP
with NoIP DNS my-AWAY-domain.com
Router B OpenWrt with wireguard install
= LAN 10.5.5.1
with WAN 126.96.36.199
Clients B = 10.5.5.5-10.5.5.33
with Router 10.5.5.1
with DNS 10.5.5.1 & 188.8.131.52
Before posting here I've been trying my best to get it to work with no success.
Really wish someone can help me out with this.
After lot of time spent reading the wireguard website and looking at the simplicity of the thing, I thought it would have been as easy as setting up a pptp connection on a mac but unfortunately it is not.
I assume your goal is to connect your two private networks, each of them behind another edge router?
It gets a bit tricky then. Not because any part of this in itself would be horribly complicated, but because you got a slightly more elaborate setup on your hands, and the whole will not work if you got any part of it wrong.
set up Wireguard on both of your OpenWrt devices
on each OpenWrt devices, enter the respective other peer's data (public key and IP range)
on the edge router in front of the OpenWrt device that acts as "server" have Wireguard's listening port forwarded to the OpenWrt device
if you want to reach the "outer" network around your OpenWrt devices through Wireguard, it becomes even more complicated
Not really "engineers", but this is definitely a topic for advanced users with at least a cursory knowledge about networking. With OpenWrt, most of the topics beyond basic operation are. Especially with anything beyond a basic setup, Wireguard definitely is not something that can be configured with just a few clicks (yet).
This is actually simple and Wireguard makes things quite easy.
You merely have to stand up the tunnels.
You have to open the UDP ports that you selected as the listening port (at least one device must have the UDP port status and opened on the firewall and port forward on the "Gateway," the other can use keepalive)
You now need to number your tunnels, the scheme you listed above appears OK
finally got it working on 18.06 after lot of reading,
its much easy enough compared to openvpn
routing too is easier compared to openvpn though in the latter part of routing configs is to be done within, which then, yes, make the routing too more easier than openvpn.
As per illustrative setup above: Actually no ports need to be open, Wireguard will just connect as per what is understand in the wireguard whitepaper.
Lost of wireguard handshake connection when WAN IP changed on Endpoint gateway:
Lan and Wireguard interface need to be restarted
or the whole openwrt device will need restarting after config - after ip change on both side - after ip change on either side.
WireGuard does not update Endpoint host IP automatically after the ISP provided IP changed on the endpoint. Either interface of the local device or the device itself need to be restarted. Eratic here, sometime connection is good after only LAN is restarted, sometime the WG inerface only, sometime both interface require restarting, sometime a reboot is ok and worst case a power off and power on is required.
event with cron no good : */6 * * * * ping -4c 2 endpointhostname
Device concerned here are TP-Links 1043, 4300, C2600, Archer C7, Netgear R7000
config are as such:
Wireguard configured on OPENWRT endpoints
OPENWRT devices possesses cron executed process to verify gateway ip changed, to update DDNS, to send mail of new ip to guy x mail and to reboot the device 10minutes after gateway ip have been changed
Gateway is NOT the WG openwrt device in above config
It's not much better, really, but I'm assuming you are asking questions.
This is true, as I mentioned in a post above. However, even if both the server and the client side change IPs, none of the routers in the setup needs to be restarted.
It is enough to restart the Wireguard interface on the client side OpenWrt device. Again, there is a small "wireguard_watchdog" script in wireguard-tools now to help with that. It is called on a regular basis from cron, checks if the Wireguard connection is still active, and restarts it if not. See the commit message for instructions.
By default, WireGuard tries to be as silent as possible when not being used; it is not a chatty protocol. For the most part, it only transmits data when a peer wishes to send packets. When it's not being asked to send packets, it stops sending packets until it is asked again. In the majority of configurations, this works well. However, when a peer is behind NAT or a firewall, it might wish to be able to receive incoming packets even when it is not sending any packets. Because NAT and stateful firewalls keep track of "connections", if a peer behind NAT or a firewall wishes to receive incoming packets, he must keep the NAT/firewall mapping valid, by periodically sending keepalive packets. This is called persistent keepalives . When this option is enabled, a keepalive packet is sent to the server endpoint once every interval seconds. A sensible interval that works with a wide variety of firewalls is 25 seconds. Setting it to 0 turns the feature off, which is the default, since most users will not need this, and it makes WireGuard slightly more chatty. This feature may be specified by adding the PersistentKeepalive = field to a peer in the configuration file, or setting persistent-keepalive at the command line. If you don't need this feature, don't enable it. But if you're behind NAT or a firewall and you want to receive incoming connections long after network traffic has gone silent, this option will keep the "connection" open in the eyes of NAT."
But from basics network understanding, me too I thought ports needed to be opened.
on some setups ports were opened and forwarded and on some not. So far works for both and I concluded that no ports fwd are required. With ports closed on setups where there were opened/fwdd ports, WG keep handshaking after reboots and after days online with various ISP gateway IP changed.