Once you have what appears to be the basic config on both routers, if you are still having trouble, come back to this thread and post the latest config files from each router. We'll get things working, I'm sure.
1 Like
Okay, I built it back up. The WireGuard interfaces see other (the packet RX and TX counts go up together). Here are the changes made to the config files. I bet there's something simple I'm missing in "list allowed_ips" to route all traffic from the second router over its WireGuard interface.
I tried testing the second router config with list allowed_ips '192.168.4.0/24' to push all traffic from the second router to the main router's LAN_PORT_4 (after opening the firewall properly) and I couldn't connect to anything on 192.168.4.0. Even with 0.0.0.0/24, nothing seemed to go out onto the WireGuard interface.
Gotta be something simple I'm missing!
Thank you.
Main Router /etc/config/network (additions only)
config interface 'WireGuard'
option proto 'wireguard'
option private_key 'X1'
option listen_port '51820'
list addresses '10.11.14.1/24'
config wireguard_WireGuard
option description 'Second'
option public_key 'Y2'
option endpoint_host '192.168.3.215'
option endpoint_port '51820'
option route_allowed_ips '1'
list allowed_ips '10.11.14.2/32'
option persistent_keepalive '5'
Main Router /etc/config/firewall (additions only)
config zone
option name 'WireGuard'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'LAN_Port_3'
config forwarding
option src 'WireGuard'
option dest 'WAN'
Second Router /etc/config/network (additions only)
config interface 'WireGuard'
option proto 'wireguard'
option private_key 'Y1'
option listen_port '51820'
list addresses '10.11.14.2/24'
config wireguard_WireGuard
option description 'Main'
option public_key 'X2'
option endpoint_host '192.168.0.1'
option endpoint_port '51820'
option route_allowed_ips '1'
option persistent_keepalive '5'
list allowed_ips '10.11.14.1/32'
Second Router /etc/config/firewall (additions only)
config zone
option name 'WireGuard'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'WAN'
config forwarding
option src 'WAN'
option dest 'WireGuard'
Your list allowed_ips entries are wrong. They need to contain the IP(s) or subnets that you want to allow traffic from and traffic to in the tunnel.
For example, if you had two LANs using 192.168.0.0/24 (call this LAN A) and 192.168.1.0/24 (LAN B) and wanted to connect them via wireguard then the router in LAN A would need list allowed_ips 192.168.1.0/24 (because you want to let traffic from that subnet out of the tunnel and traffic to that subnet into the tunnel) and the router in LAN B would need list allowed_ips 192.168.0.0/24.
If you wanted one LAN to route traffic out of the other LANs internet connection (say LAN B using LAN A's internet) then you would have list allowed_ips 0.0.0.0/0 on the LAN B router.
krazeh,
Thanks! I think we're getting closer to where my misunderstanding of how WireGuard works is. I think I'm just accustomed to the client-server model.
So, I tried the following changes and it effectively stops all traffic. Though the keep alive packets keep the counters going up on the two WireGuard interfaces, I don't see packets associated with traffic increasing the counters. They seem like they're getting dropped.
Would it be a firewall issue? I've intentionally kept the firewall zone for the WireGuard interface wide open until I get things to work.
Main Router (Router with LAN A in your example) /etc/config/network and firewall
config interface 'WireGuard'
option proto 'wireguard'
option private_key 'X1'
option listen_port '51820'
list addresses '10.11.14.1/24'
config wireguard_WireGuard
option description 'Second'
option public_key 'Y2'
option endpoint_host '192.168.3.215'
option endpoint_port '51820'
option route_allowed_ips '1'
list allowed_ips '192.168.3.215/32'
option persistent_keepalive '5'
Second Router (Router with LAN B in your example) /etc/config/network and firewall
config interface 'WireGuard'
option proto 'wireguard'
option private_key 'Y1'
option listen_port '51820'
list addresses '10.11.14.2/24'
config wireguard_WireGuard
option description 'Main'
option public_key 'X2'
option endpoint_host '192.168.0.1'
option endpoint_port '51820'
option route_allowed_ips '1'
option persistent_keepalive '5'
list allowed_ips '0.0.0.0/0'
Again, Second Router uses its WAN interface to connected to LAN_PORT_3 interface (192.168.3.0) of the Main Router. The Main Router has its WAN inteface connected to the ISP.
Thank you.
While WG technically treats all devices as peers, you can still think of it with a server/client relationship insofar as which device initiates the connection to another device. In my case, personally, I have a road-warrior type WG configuration where my OpenWrt WG endpoint at home is the "server" and my devices that travel with me (i.e. phone, travel router, etc.) are the "clients" that initiate a connection back to my home network.
Assuming that router B is the one to initiate the connection, you can make the config look like this and it should work:
Router A (primary) Network Config
config interface 'WireGuard'
option proto 'wireguard'
option private_key 'X1'
option listen_port '51820'
list addresses '10.11.14.1/24'
config wireguard_WireGuard
option description 'Second'
option public_key 'Y2'
option route_allowed_ips '1'
list allowed_ips '10.11.14.2/32'
option persistent_keepalive '25'
Router B (secondary) Network Config
config interface 'WireGuard'
option proto 'wireguard'
option private_key 'Y1'
list addresses '10.11.14.2/32'
config wireguard_WireGuard
option description 'Main'
option public_key 'X2'
option endpoint_host '192.168.13.1'
option endpoint_port '51820'
option route_allowed_ips '1'
option persistent_keepalive '25'
list allowed_ips '0.0.0.0/0'
Your firewall files probably still need to be fixed -- they are likely not what you want. But in order to determine the firewall rules that are appropriate, we need to understand the desired operation -- what is allowed, what is prohibited for both inter-VLAN routing as well as internet access, and also the access to the router itself for administration.
1 Like
The peer that has listen_port configured should not have any endpoint_host set. It listens on the port, from anywhere. Generally this one is considered a server-- it can take multiple connections on that listen_port, provided the other peer exists in a config wireguard_ section. The identity of the other peers will be determined by their public keys, which need to be unique.
The other peer(s) should have endpoint_host pointing at the "server's" IP, and endpoint_port being the listen_port of the server, and no listen_port of their own. Just like at the server, they will refuse to communicate unless the other peer (server) public key matches what is shared in the config wireguard_ section.
Next consider IP addresses and allowed_ips. Since a Wireguard tunnel is an interface, in the simplest case it holds one IP address, which is part of a network that at least includes the other end of the tunnel. In a point to point scheme, one IP would be .1 and one would be .2. This still requires a netmask of at least /30 to include both endpoints and the .0 network and .3 would be reserved for broadcast. Unless you're trying to be real stingy with IPs it is straightforward to just use a /24 even if at first you only have two endpoints. If you later add another device on the same network, its IP might be .3 -- and .2 and .3 could communicate with each other (via two hops to the server) since they are both in the /24 network.
allowed_ips is a sort of very basic access restriction in the Wireguard kernel. After decrypting / unwrapping a packet, the destination end of the tunnel looks at the source IP in the packet, and if it does not match an allowed_IP, the packet is silently dropped, making this feature a good way to break things.
Consider the "road warrior" use case. The road warrior has an IP of its end of the tunnel. All traffic from the road warrior has this source IP. Even if there is another network behind that IP (e.g. a basic travel router where the objective is "share the VPNd Internet" without making a whole site-to-site LAN), the users on that LAN will be NATd into the tunnel IP. Thus at the server end the allowed_ip is simply the road warrior or travel router's Wireguard tunnel IP with a /32.
Note that the matching IP needs to be configured into the main interface block in the road warrior. Unlike OpenVPN, Wireguard does not push clients their IP addresses. They need to be statically defined in advance, and manually properly matched.
The packets coming back to the road warrior are the result of its requests for the Internet, so they may have any source IP. The allowed_ips should be set to 0.0.0.0/0. This is where route_allowed_ips is also useful. Activating this option generates a routing table entry (or two, using the trick of splitting 0.0.0.0 in half) so that requests for an allowed IP (the whole Internet in this case) route out through the Wireguard tunnel. That is what a road warrior wants. A server serving on a /32 basis does not need route_allowed_ips. Configuring the interface with a /24 puts all the client IPs into the routing table automatically.
Specific to the OPs case, running Wireguard tunnels around the LAN seems pointless at first-- until you realize that means you can treat the whole LAN as a cloud like untrustworthy mess like the Internet. It isn't as necessary to set up a bunch of VLANs and firewall zones for security. Instead security is realized point to point by what lies beyond the ends of the VPN tunnels.
3 Likes
I agree with this, in general, but it may depend on the rest of the network's structure and requirements. The extra subnets may be needed for other purposes. I'm hoping the OP can clarify the reasoning for the VLANs and the security/routing considerations for each so we can clean up the firewall.
Hey all.
Thanks for helping me sort this all out. mk24, your explanation is very helpful and makes a lot of sense.
I've changed the configuration per psherman's suggestion two posts up (using an endpoint host of 192.168.3.1 instead). The WireGuard interfaces can see other as confirmed with packet counts going up and the handshake being identified on the "Status" page of Luci. However, traffic is somewhere being squashed. I can't get traffic out. The TX counter on secondary router's (B) WireGuard interface seems to go up with the traffic that is trying to get out. But the RX counter on the primary router (A) doesn't go up commensurately (just goes up with the keep-alive packets it looks like).
So then I tried to change the firewall a bit thinking maybe that's where we have a problem now...On the primary router (A), I put the WireGuard interface on the LAN_PORT_3 firewall (which manages the interface that router B is on). On the secondary router, I put the WireGuard interface on the LAN_PORT_1 interface (since I'm plugged in to that port/interface when I'm testing WireGuard on router B). No change.
Relative to the VLANs, the primary router (A) is quite a busy router managing lots of different devices that need to be isolated from each other. This is why it has the VLANs. Its LAN_PORT_3 serves the secondary router (B). That router B is remote (3 miles away on a pair of Ubiquiti dishs). Within the secondary router are additional VLANs to isolate the users on that remote router.
It's important to note that the firewall and VLAN configurations as they're setup (before any WireGuard implementation), work as we designed them so we'd like to preserve that firewall setup (so that the different VLANs on both routers can't talk to each other). We don't need a unique firewall for WireGuard interfaces if it can fold in to the existing framework however. Maybe it's nonsensical to have a firewall for the WireGuard interfaces given its tunneling approach?
So, to summarize where we're at: The WireGuard interfaces talk to each other with the keep-alives and handshakes, but traffic seems to not get routed properly.
Thanks so much folks, for taking the time to help us with this.
Just add the wireguard interfaces to the appropriate firewall zones on each router, so LAN_Port_3 on the main router and WAN on the second router.
A plain English description of what you hope to achieve with this remote network in terms of inter-VLAN routing (and any directionality) would be useful.
For example (just laying out scenarios):
- secondary router's LAN_Port_3 can reach all other networks on the primary router.
- all other networks on the secondary router will get internet access, but be prohibited from connecting to the other networks on the primary router.
- all primary router networks are prohibited from initiating connections with the networks on the secondary router
I recommend putting the Wireguard network into its own zone on both sides (let's call it the vpn zone for now).
On the 'client' side (secondary router), enable masquerading on the vpn zone. On the primary side ('server'), you don't need masquerading.
The forwarding rules on both networks will be determined by the description that I have requested. You may possibly also need some static routes defined, depending on the specific goals.
That sounds like an allowed_ips problem. You could set allowed_ips to 0.0.0.0/0 on both ends (without route_allowed_ips) to prevent allowed_ip rejection. I'm not sure what happens if you leave allowed_ips out of the configuration entirely.
Can you ping from one end of the tunnel to the other, using the IP addresses on the tunnel interfaces (configured in Wireguard)? This doesn't depend much on the firewall other than allowing input (ICMP) on the interface.
The tcpdump program would be useful here to see packets entering and leaving.
I would approach this a bit differently...
- I'd set allowed_ips to 0.0.0.0/0 on the secondary router.
- On the primary router, I'd leave allowed_ips as 10.11.14.2/32
- on the primary router (if traffic should be allowed when initiated by the devices on the networks on the primary network), I'd setup forwarding rules (LAN_PortX > vpn) and static routes (for example: 192.168.13.0/24 via 10.11.14.2)
- then on the secondary router, I'd enable forwarding from vpn > LAN_PortX.
Thanks all!
For an English description, for now what we're trying to do is have all traffic in and out of the secondary router (from all of its interfaces) to pass through the WireGuard VPN to have that additional layer of encryption, given that it's remotely located via the Ubiquiti dishes. The secondary router should only be able to access the internet (through the primary router's WAN interface) outbound. And the primary router's LAN interface (which correspond to ethernet jacks 1 and 2 on the router) should be able to access the secondary router (this lets us access the secondary router via ssh/Luci). The current firewall zones permit that traffic setup.
So, having said all that, we can now get the WireGuard interface to work! The final key was enabling masquerading on the secondary router's firewall zone that was attached to the WireGuard interface.
So, we're basically there thanks to all your help! What an education and a valuable thread!
It's also clear that we didn't understand how the firewall would work with the new WireGuard interface. To explain, in order to get the WireGuard interface to work on the secondary router with its own separate firewall zone (let's call that zone WG), we had to allow it to forward to the WAN and allow forwarding from LAN_PORT_1. And then I had to allow LAN_PORT_1 to forward to the WG zone. In other words, see below. In retrospect, this makes sense. But is another piece to the puzzle we were missing since we didn't have a solid understanding of how the tunnel worked.
config forwarding
option src 'WG'
option dest 'WAN'
config forwarding
option src 'LAN_PORT_1'
option dest 'WG'
So, I think it this point we're in a position to configure the WireGuard firewall to function the same as our original configuration (as it did without the WireGuard interface working).
It is interesting, that when I stop the WireGuard interface through Luci on the secondary router, internet access doesn't return. The WAN interface on this secondary router has to be restarted to restore internet access.
I'll come back tomorrow to write a summary so the solution to my experience is available for others to read and I'll mark the thread as solved.
1 Like
Glad everything is working as you want now!
this is not unexpected, actually. It is a quirk of the way that the WG interface comes up -- it effectively replaces the existing routing table and does not restore it when the interface goes down. In order to resolve this, you can do one of two things:
- put a gateway metric value on your WAN
- use the hotplug.d scripts to restart the WAN interface when WG goes down.
Meanwhile...
If your problem is solved, please consider marking this topic as [Solved]. See How to mark a topic as [Solved] for a short how-to.
Hi all.
psherman, what a great idea, thanks! We added the hotplug.d script to fix that little routing table quirk!
However, I was all ready to come back and summarize the problem/solution and mark the thread as solved so maybe it could help other folks, but...
We thought we had it but it isn't quite there yet. We're able to get one VLAN on the secondary router to be able to access the internet. However, the other VLANs can't. That's really confusing to us.
We decided to draw a simplified diagram of our network to help explain. Relative to our conversation thus far, the main router is the ISP Router and the secondary router is Router 3. The VLAN/Firewall names are in the color corresponding their associated routers. I hope it's readable.
Without the WireGuard interfaces enabled, everything works as intended. But with the WireGuard interfaces enabled and functioning only Router 3a can access the internet just fine through WireGuard. Router 3b and wireless devices on Router 3 can't. Which is really strange.
The firewall configuration for Router 3 is below. I can't see why internet access works for only the R3_LAN_PORT_1 interface. Do you think we're missing something here?
Also, without the WireGuard interface, we are able to ssh 192.168.3.215 into Router 3 from the ISP Router. When the WireGuard interface is up, we can only access Router 3 by ssh 10.11.14.2. That's not a big deal, but curious if we can route 192.168.3.215 into Router 3 when the WireGuard interface is up. We tried some static route variations to no avail.
Thanks everyone.
Router 3 /etc/config/firewall
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'config zone
option output 'ACCEPT'
option mtu_fix '1'
option network 'wan wan6'
option masq '1'
option forward 'REJECT'
option input 'DROP'
option name 'WAN'config rule
option name 'Allow-DHCP-Renew'
option proto 'udp'
option dest_port '68'
option target 'ACCEPT'
option family 'ipv4'
option src 'WAN'config rule
option name 'Allow-Ping'
option proto 'icmp'
option icmp_type 'echo-request'
option family 'ipv4'
option target 'ACCEPT'
option src 'WAN'config rule
option name 'Allow-IGMP'
option proto 'igmp'
option family 'ipv4'
option target 'ACCEPT'
option src 'WAN'config rule
option name 'Allow-DHCPv6'
option proto 'udp'
option src_ip 'fc00::/6'
option dest_ip 'fc00::/6'
option dest_port '546'
option family 'ipv6'
option target 'ACCEPT'
option src 'WAN'config rule
option name 'Allow-MLD'
option proto 'icmp'
option src_ip 'fe80::/10'
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family 'ipv6'
option target 'ACCEPT'
option src 'WAN'config rule
option name 'Allow-ICMPv6-Input'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
list icmp_type 'router-solicitation'
list icmp_type 'neighbour-solicitation'
list icmp_type 'router-advertisement'
list icmp_type 'neighbour-advertisement'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'WAN'config rule
option name 'Allow-ICMPv6-Forward'
option dest '*'
option proto 'icmp'
list icmp_type 'echo-request'
list icmp_type 'echo-reply'
list icmp_type 'destination-unreachable'
list icmp_type 'packet-too-big'
list icmp_type 'time-exceeded'
list icmp_type 'bad-header'
list icmp_type 'unknown-header-type'
option limit '1000/sec'
option family 'ipv6'
option target 'ACCEPT'
option src 'WAN'config include
option path '/etc/firewall.user'config zone
option name 'R3_LAN_Port_4'
option output 'ACCEPT'
option network 'R3_LAN_Port_4'
option forward 'REJECT'
option input 'ACCEPT'config zone
option name 'R3_LAN_Port_3'
option output 'ACCEPT'
option network 'R3_LAN_Port_3'
option forward 'REJECT'
option input 'ACCEPT'config zone
option name 'Wireless'
option output 'ACCEPT'
option network 'Wireless'
option input 'ACCEPT'
option forward 'REJECT'config forwarding
option src 'R3_LAN_Port_4'
option dest 'WAN'config forwarding
option src 'R3_LAN_Port_3'
option dest 'WAN'config forwarding
option src 'Wireless'
option dest 'WAN'config rule
option target 'ACCEPT'
option src 'Wireless'
option name 'Wireless DHCP'
option dest_port '67-68'config rule
option target 'ACCEPT'
option src 'Wireless'
option name 'Wireless DNS'
option dest_port '53'config rule
option target 'ACCEPT'
option src 'R3_LAN_Port_4'
option name 'R3_LAN Port 4 DHCP'
option dest_port '67-68'config rule
option target 'ACCEPT'
option src 'R3_LAN_Port_4'
option name 'R3_LAN Port 4 DNS'
option dest_port '53'config rule
option target 'ACCEPT'
option name 'R3_LAN Port 3 DHCP'
option src 'R3_LAN_Port_3'
option dest_port '67-68'config rule
option target 'ACCEPT'
option src 'R3_LAN_Port_3'
option name 'R3_LAN Port 3 DNS'
option dest_port '53'config zone
option output 'ACCEPT'
option name 'R3_LAN_Port_1'
list network 'R3_LAN_Port_1'
option input 'ACCEPT'
option forward 'REJECT'config forwarding
option src 'R3_LAN_Port_1'
option dest 'WAN'config zone
option name 'R3_LAN_Port_2'
option network 'R3_LAN_Port_2'
option output 'ACCEPT'
option forward 'REJECT'
option input 'ACCEPT'config forwarding
option src 'R3_LAN_Port_2'
option dest 'WAN'config rule
option src 'R3_LAN_Port_2'
option name 'R3_LAN Port 2 DHCP'
option target 'ACCEPT'
option dest_port '67-68'config rule
option src 'R3_LAN_Port_2'
option name 'R3_LAN Port 2 DNS'
option target 'ACCEPT'
option dest_port '53'config rule
option dest_port '67-68'
option src 'R3_LAN_Port_1'
option name 'R3_LAN Port 1 DNS'
option target 'ACCEPT'config rule
option dest_port '53'
option src 'R3_LAN_Port_1'
option target 'ACCEPT'
option name 'R3_LAN Port 1 DNS'config rule
option name 'Luci from WAN'
list proto 'tcp'
option target 'ACCEPT'
option dest_port '80'
option src 'WAN'config rule
option name 'Luci from WAN SSL'
list proto 'tcp'
option target 'ACCEPT'
option dest_port '443'
option src 'WAN'config rule
option name 'SSH from WAN'
list proto 'tcp'
option target 'ACCEPT'
option dest_port '22'
option src 'WAN'config zone
option name 'WireGuard'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'WireGuard'config forwarding
option src 'WireGuard'
option dest 'WAN'config forwarding
option src 'R3_LAN_Port_1'
option dest 'WireGuard'config forwarding
option src 'WireGuard'
option dest 'R3_LAN_Port_1'config forwarding
option src 'WAN'
option dest 'WireGuard'config rule
option name 'Luci from WireGuard'
option src 'WireGuard'
option dest_port '80'
option target 'ACCEPT'config rule
option name 'Luci from WireGuard SSL'
option src 'WireGuard'
option dest_port '443'
option target 'ACCEPT'config forwarding
option src 'R3_LAN_Port_2'
option dest 'WireGuard'config forwarding
option src 'WireGuard'
option dest 'R3_LAN_Port_2'config forwarding
option src 'R3_LAN_Port_3'
option dest 'WireGuard'config forwarding
option src 'WireGuard'
option dest 'R3_LAN_Port_3'config forwarding
option src 'Wireless'
option dest 'WireGuard'config forwarding
option src 'WireGuard'
option dest 'Wireless'config forwarding
option src 'R3_LAN_Port_4'
option dest 'WireGuard'config forwarding
option src 'WireGuard'
option dest 'R3_LAN_Port_4'
Try enabling masquerading on the WireGuard firewall zone.
FWIW, that firewall has a bunch of unnecessary rules, but they probably don't cause any issues here.
Also, this topology is really odd... why not just have a single router create all of the networks (and firewall rules governing the inter-VLAN routing). The rest of the routers would then simply be dumb APs/switches. This would simplify your routing considerably and make management much easier.
1 Like
Your diagram isn't fully complete, since the routers hold more than one IP address.
Relevant to this situation we have:
ISP router
WAN : an Internet IP. If CGNAT, not a public routable IP, you have to be sure it doesn't conflict with any of your networks.
LAN3 : 192.168.3.1/24
Other LANs : .4.1, .8.1 etc -- not relevant to this problem
WG0 : 10.11.14.1/24
Router 3:
WAN 102.168.3.215/24
WG0 : 10.11.14.2/24
LAN1 : 192.168.11.1/24
LAN2 : 192.168.12.1/24
Router 3A:
WAN : 192.168.11.101/24
LAN : 192.168.6.1
Router 3B is basically the same situation as 3A.
Now working backwards from the desktop computer which is an endpoint user at the Router 3 site, Router 3A should NAT its Internet request from 192.168.6.x to 192.168.11.101 and forward it to 192.168.11.1 which is router 3. This is the same as if Router 3A were connected to an ISP directly. Basically Router 3 is the ISP for everything at site 3*. Router 3 then NATs to 10.11.14.2 and forwards to 10.11.14.1, which is Router 1. Note that this packet actually travels Wireguard encrypted on the 192.168.3.0 network. Router 1 unwraps the packet back to discover it is from 10.11.14.2 then NATs that to its public IP and forwards to the ISP.
This can be observed by running a traceroute on the desktop. Except of course that traceroute doesn't see what is outside the tunnel of packets that go via VPN. First try this with a numeric IP known to exist on the Internet such as 8.8.8.8. If that works but a DNS name does not work, you need to look at DNS configurations through the network.
- and as such, as psherman suggested you don't need separate networks for the WAN side of routers 3a and 3b. Really also as psherman said, you don't need routers 3a and 3b at all-- everything at site 3 could be bridged into Router 3 or run as isolated LANs on router 3.
2 Likes
Thanks all. We have it working now! This thread will be marked [Solved].
psherman: Agree that the network design is clunky. It wasn't designed from the ground-up but rather came to be over time and certainly could use improvement.
Relative to the firewall setup on Router 3, we just had it wide open when setting up WireGuard to make sure it wasn't working against us. It's since been closed up. Though, as you point out, since it's not exposed to the outside world, we're not too worried about it.
So, here's our problem/solution summary to add to the other excellent commentary from psherman, mk24 and krazeh in case this thread is happened upon by others. We hope it's helpful.
Thanks so much everyone! We are grateful for your help and to the community for providing this forum.
Problem: Getting WireGuard to work between two routers on a separate VLAN. One router is ISP-facing, the other is remote.
Reason for this need: The remote router (Router 3) is located 3 miles away on a set of 5 GHz Ubiquiti dishes in an urban area. Though there is WPA2 encryption on this link, we wanted another layer of security. WireGuard seemed like a great fit rather than OpenVPN.
Our network architecture is sketched in our previous post above (note, mk24 pointed out that it isn't really complete).
Solution:
ISP-facing router /etc/config/network (relevant part only, keys removed)
config interface 'WireGuard'
option proto 'wireguard'
option private_key X1
option listen_port '51820'
list addresses '10.11.14.1/24'
config wireguard_WireGuard
option public_key Y2
option route_allowed_ips '1'
option persistent_keepalive '25'
option description 'Router 3a'
list allowed_ips '10.11.14.2/32'
list allowed_ips '192.168.11.204'
ISP-facing router /etc/config/network (relevant part only, keys removed)
config forwarding
option src 'LAN'
option dest 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'LAN_Port_3'
config forwarding
option src 'LAN_Port_3'
option dest 'WireGuard'
config zone
option name 'WireGuard'
option output 'ACCEPT'
option masq '1'
option input 'ACCEPT'
option forward 'ACCEPT'
list network 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'WAN'
Remote Router 3 /etc/config/network (relevant part only, keys removed)
config interface 'WireGuard'
option proto 'wireguard'
option private_key X2
list addresses '10.11.14.2/32'
config wireguard_WireGuard
option description 'Router ISP'
option public_key X2
option endpoint_port '51820'
option persistent_keepalive '25'
option route_allowed_ips '1'
list allowed_ips '0.0.0.0/0'
option endpoint_host '192.168.0.1'
Remote Router 3 /etc/config/firewall (relevant part only)
config zone
option name 'WireGuard'
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'ACCEPT'
list network 'WireGuard'
option masq '1'
config forwarding
option src 'WireGuard'
option dest 'WAN'
config forwarding
option src 'LAN_Port_1'
option dest 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'LAN_Port_1'
config forwarding
option src 'WAN'
option dest 'WireGuard'
config forwarding
option src 'LAN_Port_2'
option dest 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'LAN_Port_2'
config forwarding
option src 'LAN_Port_3'
option dest 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'LAN_Port_3'
config forwarding
option src 'Wireless'
option dest 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'Wireless'
config forwarding
option src 'LAN_Port_4'
option dest 'WireGuard'
config forwarding
option src 'WireGuard'
option dest 'LAN_Port_4'
Explanation (as we understand it):
The two interfaces have their own IP address: 10.11.14.1 for the ISP Router and 10.11.14.2 for the remote Router 3. We can ssh into the remote Router three from the ISP router on 10.11.14.2 (based on our firewall rules, not shown) when the WireGuard interface is up (ifup WireGuard). And if it's ever down (ifdown WireGuard) we can ssh in on 192.168.3.215.
Because we want all traffic on remote Router 3 to pass through the WireGuard interface, we set list allowed_ips '0.0.0.0/0'. Since that interface needs to talk to the ISP Router, option endpoint_host
is set to 192.168.0.1. The interface is attached to its own firewall zone (labeled WireGuard in our case). Masquerading is set to ensure no routing conflicts with our network architecture.
On the ISP-facing router, list allowed_ips is set to the interface IP of Router 3 (10.11.14.2/32) so that only traffic destined for Router's 3 WireGuard interface is carried over the WireGuard connection. option endpoint_host is not set since it will simply listen for a connection from anywhere and accept it if the keys are right. We also added 192.168.11.204 in list allowed_ips so we can access devices on Router 3a from the ISP Router (prior to WireGuard, this was done with a static route). The interface is attached to its own firewall zone (labeled WireGuard in our case). Masquerading is set to ensure no routing conflicts with our network architecture.
When the WireGuard interface is taken down (which shouldn't really happen, but just in case), the routing table is not rewritten to take that into account, so we added a rule for hotplug.d in /etc/hotplug.d/iface/99-wan-reup on Router 3 (really isn't necessary on the ISP-facing router since only IP was included in the routing table rather than all subnets). This rule brings the WAN interface up again any time any other interface went down so that the routing table is restored to a pre-WireGuard setup.
Router 3 /etc/hotplug.d/iface/99-wan-reup
[ "${ACTION}" = "ifdown" ] && {
ifup wan
logger -t hotplug "Device: ${DEVICE} / Action: ${ACTION} so WAN has been restarted"
}
The endpoint_host is the "outside" of the tunnel, it is the place on the insecure network where encrypted packets will be sent. Though it does technically work to use any IP held by Router 1, it makes the most sense to use 192.168.3.1 as that is the interface directly facing Router 3.
Since your main concern is someone breaking into the wireless link, that .3.0 network should be strictly firewalled so that the only thing allowed into or out of either end is Wireguard packets. Then as you said, someone on the .3.0 network but without the Wireguard keys still cannot make any access to anything useful on your networks. This means necessarily that site 3 cannot have Internet access without Wireguard-- the so called "kill switch" functionality that is inherent in only allowing a route through Wireguard.
1 Like
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.