Wireguard, iptables and access to dietpi from another VLAN

Troubleshooting
1

I am trying to ssh to DietPi that has a running Wireguard client from a PC on another VLAN. As my issue seems to be closely related with what was discussed in this topic: Wireguard Client & iptables I have based my iptables rules on the proposed solutions there. However, while the solution works fine as long as I am accessing DietPi from a machine that is on the same VLAN, the access is denied when I move to another VLAN.

I have the following setup. PC on VLAN 1, Dietpi running Wireguard and Motion Eye on VLAN 2 and an IP camera on VLAN 3. As long as Wireguard is down on Dietpi everything works as expected. However, once Wireguard is up, the setup works as desired only if PC is on VLAN 2.

Here is my Wireguard config:

PostUp = iptables -I INPUT 1 -i eth0 -p tcp -s 192.168.2.0/24 --dport 22 -j  ACCEPT
PostUp = ip rule add table 200 to 192.168.3.5
PostUp = ip route add table 200 default via 192.168.2.1
PostUp = iptables -I OUTPUT 1 -s 192.168.2.0/24 -d 192.168.3.0/24 -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
PostUp = iptables -I INPUT 1 -s 192.168.3.0/24 -d 192.168.2.0/24 -p tcp -m state --state ESTABLISHED -j ACCEPT
PostUp = iptables -I OUTPUT 1 -o eth0 -m conntrack --ctstate  ESTABLISHED,RELATED -j ACCEPT 
PostUp = iptables -A OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT
PreDown = iptables -D INPUT -i eth0 -p tcp -s 192.168.2.0/24 --dport 22 -j  ACCEPT
PreDown = ip rule delete table 200 to 192.168.3.5
PreDown = ip route delete table 200 default via 192.168.2.1
PreDown = iptables -D OUTPUT -s 192.168.2.0/24 -d 192.168.3.0/24 -p tcp -m state --state NEW,ESTABLISHED -j ACCEPT
PreDown = iptables -D INPUT -s 192.168.3.0/24 -d 192.168.2.0/24 -p tcp -m state --state ESTABLISHED -j ACCEPT
PreDown = iptables -D OUTPUT -o eth0 -m conntrack --ctstate  ESTABLISHED,RELATED -j ACCEPT  
PreDown = iptables -D OUTPUT ! -o %i -m mark ! --mark $(wg show %i fwmark) -m addrtype ! --dst-type LOCAL -j REJECT

Initially I thought that it would suffice to add:

PostUp = iptables -I INPUT 1 -i eth0 -p tcp -s 192.168.1.0/24 --dport 22 -j  ACCEPT

for VLAN 1, but that didn’t work. I have also tried to add output rules for that IP range and using route table, but DietPi remains unreachable with Wireguard up from VLAN 1. At this point I run out of ideas what else I could try and look forward to any suggestions.

EDIT: Just for clarification, VLAN 1 ip range: 192.168.1.0/24, VLAN 2 ip range: 192.168.2.0/24.

2

PostUp = ip rule add table 200 to 192.168.0.0/16

3

Thanks. That was simple and indeed solves the problem. However, is there a potential risk of DNS leaks when using /16? Of course, I can simply adapt the solution to a fixed IP, but I am curious whether adding this route could result in use of router’s default DNS server instead of the one provided by Wireguard.

After adding this additional route, I realized that some of the iptables rules are not needed anymore so I tried to remove what was redundant. What is the following rule used for?

iptables -I OUTPUT 1 -o eth0 -m conntrack --ctstate  ESTABLISHED,RELATED -j ACCEPT

I took it from another post, but I am not sure what purpose does it serve.

Edit: It also made me think whether it is safe to leave default Input and Forward rules on Accept. I read some other discussion on this forum where it was mentioned that using a restrictive firewall on DietPi is not needed as it is protected by router’s firewall in most home settings. Does the recommendation change when DietPi is connected to a commercial VPN?

4

It’s a private IP space, to whom are you going to leak? Anyway, you can narrow it down to the address space that interests you.

To allow answers.

When connected to a vpn, the dietpi is exposed to the internet, so it is wise to limit the exposure by opening only the ports needed and rejecting everything else.

5

It’s a private IP space, to whom are you going to leak? Anyway, you can narrow it down to the address space that interests you.

I see. I thought that it could possibly also include IP address of the gateway and pass the query to ISP’s DNS. However, it’s good to know that this is not the source of the leaks. While trying different settings I must have changed something as sporadically I was getting DNS leaks, but it seems to be fixed now again.

When connected to a vpn, the dietpi is exposed to the internet, so it is wise to limit the exposure by opening only the ports needed and rejecting everything else.

Thank you. I modified the firewall. Does that mean that even if I use WIreguard as a “client”, the connection is bi-directional and the server/ other peers connected to the same server are able to access my device? Are there any logs on DietPi that I could check to make sure that my machine was not compromised during the time I was figuring out the settings?

6

Any correctly configured vpn provider would not let other users access your device, or other internet users. However, since you are not in control of that, you cannot be sure, hence it makes more sense to treat it as unsecure network.
Regarding the dns server of the router, you can add a rule to prohibit port 53 on the gateway. But most certainly the nameservers used when vpn is up are changed into the ones provided by the vpn.

7

Thank you for all the info. I will mark the topic as solved.

1 Like