Raspberry Pi 4 Wireless WireGuard client over a tagged VLAN

[realies]

@psherman

This is exactly backwards of what it should be....
input = drop or reject
forward = drop or reject
output = accept

I'm sorry, I must have misread the order in the instructions before. I reconfigured the vlan zone to be input=reject, output=accept, forward=reject.

When I changed input=reject, the USG stopped being able to see the Pi on 192.168.101.1.

Connecting via port 1 on the switch (VLAN 101 native network), I can no longer see 192.168.101.1 (Pi) and 192.168.101.2 (USG).

Allowing the vlan zone to forward to wan instead of vpn does not help with seeing 192.168.101.0/24. It makes the Pi lose public internet access despite wlan0 being connected. After a couple of reboots and interface restarts the Pi can access the public internet. 192.168.101.2 (USG) is still unreachable from the Pi.

The computer on port 1 doesn't see anything at the moment. Changing vlan.input=accept makes the USG see 192.168.101.1 (Pi). The computer on port 1 also starts seeing 192.168.101.1 but not 192.168.101.2 (USG). In this setup computer on port 1 has public internet through wlan0, and can create and use a WireGuard tunnel configured identically to the OpenWrt interface one.

Edit: USG started seeing public internet through eth2.101 with the vlan > wan and vlan.input=accept change.

[psherman]

@realies

When I changed input=reject, the USG stopped being able to see the Pi on 192.168.101.1.

Please correct me if I'm wrong... but I believe that this is actually what you want (at least long term) -- the Pi itself should not be possible to reach on VLAN 101 -- by this, I mean that you will not be able to administer the Pi on this VLAN. Internet will still route though the Pi, even if you are unable to ping the Pi (or use ssh or LuCI).

Management of the Pi happens on VLAN 1 with 192.168.100.13.

You can verify this by connecting your computer to port 1 and manually assigning the IP address info as you had done previously. You should be unable to reach the Pi itself, but you should be able to reach the internet with no issue (assuming you have the firewall forwarding setup to allow lan > wan forwarding and that the WG connection is disabled (for now).

Then, set your computer to DHCP and plug into port 2 -- you should be able to access the pi (192.168.100.13) for administrative purposes (ping, ssh, LuCI). Your internet traffic will go through the USG and probably via WAN1.

@realies

Allowing the vlan zone to forward to wan instead of vpn does not help with seeing 192.168.101.0/24.

This is expected behavior. This was intended to get internet connectivity (bypassing the WG VPN which may not be working properly), to prove that your VLANs are configured properly and that your Pi is routing in general. The forwarding has nothing to do with the 192.168.101.0/24 network's ability to access the Pi (it is the zone "input" rule which controls this aspect).

@realies

The computer on port 1 doesn't see anything at the moment. Changing vlan.input=accept makes the USG see 192.168.101.1 (Pi). The computer on port 1 also starts seeing 192.168.101.1 but not 192.168.101.2 (USG)

Yes, entirely expected. You don't need to be able to "see" the Pi in order to route through it (I know, it seems strange). VLAN 101's connection to the USG is via the USG's WAN2. Because of this, the USG treats the network as untrusted... so the fact that you can't "see" it is fine... as long as it can ping out to the internet, it doesn't matter if the USG can be "seen" from your computer (or the Pi) and it doesn't matter if it can "see" the pi from its own interface.

@realies

Edit: USG started seeing public internet through eth2.101 with the vlan > wan and vlan.input=accept change.

I am pretty sure you want to have input=drop or reject in the long term. But if it makes it easier for you to troubleshoot for now, you can set that vlan zone input rule to accept. Once everything is actually working, you'll see that you can change it to drop/reject and the internet will still work as expected.

Back to WG -- I think your WG connection is not working properly. Since you now know that allowing forwarding from vlan > wan allows normal internet connectivity via the Pi, the remaining question is about the WG connection. So... setup WG on your phone or computer with the parameters from the Pi. Make sure the Pi's WG interface is stopped, and then connect using your phone/computer and see if you get proper connectivity. If you don't, that would likely explain the earlier problems.

[realies]

@psherman

Please correct me if I'm wrong... but I believe that this is actually what you want (at least long term) -- the Pi itself should not be possible to reach on VLAN 101 -- by this, I mean that you will not be able to administer the Pi on this VLAN. Internet will still route though the Pi, even if you are unable to ping the Pi (or use ssh or LuCI).

Correct, I just assumed this would still work from the Pi:

# ping 192.168.101.2 -I eth0.101

@psherman

Management of the Pi happens on VLAN 1 with 192.168.100.13.

This still works.

@psherman

You can verify this by connecting your computer to port 1 and manually assigning the IP address info as you had done previously. You should be unable to reach the Pi itself, but you should be able to reach the internet with no issue (assuming you have the firewall forwarding setup to allow lan > wan forwarding and that the WG connection is disabled (for now).

Connected a computer to port 1 and set vlan > wan to input=reject, output=accept, forward=accept. Pinging 1.1.1.1 says ping: sendto: No route to host and pinging 192.168.101.2 says Request timeout ....

@psherman

I am pretty sure you want to have input=drop or reject in the long term.

When vlan.input is reject or drop, the computer connected to port 1 stops seeing public internet. OK, figured issuing /etc/init.d/network restart makes the computer on port 1 start seeing public internet through the Pi on wlan0 when vlan.input=reject.

@psherman

Back to WG -- I think your WG connection is not working properly.

Using the vpn interface (when connected) on the Pi seems to work fine:

root@OpenWrt:~# curl ipinfo.io --interface vpn
{
  "ip": "VPN-IP",
...

@psherman

So... setup WG on your phone or computer with the parameters from the Pi. Make sure the Pi's WG interface is stopped, and then connect using your phone/computer and see if you get proper connectivity.

Turning off WG on the Pi and making vlan forward to wan allows me to connect WG using an identical profile on the computer connected to port 1.

Stopping the computer WG client, and making vlan forward to vpn however, makes the computer connected to port 1 not be able to see anything - ping times out.

Latest firewall config (where I mostly switch between vlan>vpn and vlan>wan right now):

I'm not sure if the default route setting in each interface has anything to do with this, and which ones should have that tick box enabled and which disabled.

[psherman]

Found the problem. Enable masquerading on the vpn firewall zone.

[realies]

I was just about to say that rajkosto on IRC suggested the same and while hard to believe it actually works

Thank you for the huge amount of help and for going through all of this with me, it helped me grasp core networking concepts much better.

Now I'm considering making everything on the wan block to reject and only letting through the WG port, to prevent anything leaking over wlan0, does that sound reasonable?

[psherman]

@realies

Now I'm considering making everything on the wan block to reject and only letting through the WG port, to prevent anything leaking over wlan0, does that sound reasonable?

Yes, very reasonable. EDIT: maybe. On the wan zone, you want output = accept, input = reject and forward = reject. Are you talking about trying to do something else in terms of the block?

If you'd like one more review of your config, feel free to post the final (hopefully) version and I'll check it over.