No internet access but VPN-Site-to-Site access (through internet)

[Porfavor]

Hello,

I just setup a wireguard site-to-site connection which in general now seems to work fine. So there is a way opnsense at site A has internet access and LAN devices can also reach the other site B through the tunnel.

Unfortunately, the LAN devices at site A, which shall access the internet through opnsense at site A, seem to have no internet access besides of that. I cannot reach the web and cannot ping e.g. external IPs like 8.8.8.8. Do it's obviously not only a DNS issue. Computers at site A have OPNsense site A as default gateway.

Maybe I have mistaken or forgotten something about an interface or firewall rules (although I followed the guide). LAN interface das the default allow any rule.
Or could it be something about (outbound) NAT? I'm not familiar with this and how traffic is being passed between interfaces (I thought, the LAN firewall rule was enough).

Any help on where to start troubleshoothing appreciated.

[meyergru]

Only the initial LAN interfaces gets an "allow any" rule assigned. The rest you have to define yourself - in this case, a rule to allow the WIREGUARD group internet ("any") access.

[Porfavor]

Only the initial LAN interfaces gets an "allow any" rule assigned. The rest you have to define yourself - in this case, a rule to allow the WIREGUARD group internet ("any") access.

Thank you.
I am talking about clients at the same site, in the same LAN where the respective OPNsense Gateway is, which do not use the VPN. Why would I need to allow the Wireguard group something dere? I only mentioned the VPN thing to show that internet connection is possible in general. If I misunderstand something, I'd be happy if you could explain it.

In my understanding traffic comes to the LAN interface of the firewall and has to get to the WAN interface and then out of the firewall - and the other way around. Thats's where I am stuck.

[meyergru]

I thought your problem was that site B cannot route internet traffic via site A.

If the problem is for clients on LAN at site A to access the internet, then either their WAN access is:

- blocked by the firewall (e.g. because no "allow any" rule exists).
- not being responded to because of a lack of outbound NAT.
- diverted by a route or gateway that gets in the way because of a VPN misconfiguration (e.g. a firewall rule or routes).

Did you even try if your clients had internet access before setting up the VPN?

[Porfavor]

Actually not via this machine. I have another machine running OpenVPN and as long as this was the gateway, they could access. I just wanted to setup a new machine as I couldn't really get wireguard to work parallely to OpenVPN on this other machine and I might have messed things up there.

This machine I am talking about is just newly setup and I didn't test if the LAN had access to the internet.
I will post the settings for the firewalls and the outbound NAT later the day.

[Porfavor]

So, the NAT outbound settings are the ones in NAT.png. WAN interface firewall settings are in WAN.png and LAN firewall settings in LAN.png.
192.168.133.0/24 is the LAN I am talking about. Probaly is rule is unnecessary as I have the default allow all rule.

It's all in German. If I need to translate it, let me know.

I currently don't have the time to get into this any further. I'll do it any time the next days. However, maybe one can get something out of the rules.

[meyergru]

You seem to have a different LAN on OPT1, for which you probably want 192.168.133.0/24. There is a distinction between this subnet and "LAN Netzwerk".

But you have set up the outbound rule for that network on the wrong interface, namely LAN, where you probably wanted OPT1.

Also, in a "usual" setup, you cannot just allow access from the WAN to your LAN (which is presumably RFC1918, too. You would need to set up port forwarding rules.

[Porfavor]

Thanks again.

OPT1 is the wireguard interface which shouldn't matter in this situation?
The outbound rules have been created automatically.

Which distinction are you referring to?

Do I need to create a rule Allow IPv4 * * 192.168.133.0/24 on the WAN interface or really create an entry under port forwarding? How would that look like? I don't really get it at the moment. Maybe, you could provide an example.
I am pretty sure I didn't do port forwarding on the other machine (at least not manually).

[meyergru]

Why do you refer to 192.168.133.0/24 when that in fact is your LAN subnet with an existing outbound rule? If there is a distinction, then what does that mean or what is it supposed to achieve? It that subnet on the same interface as your LAN subnet?

Then, since you only use automatic NAT outbound rules, there is no provision made for 192.168.133.0/24 to be NATed on outbound access, which may explain why this does not work.

Frankly, I do not understand where 192.168.133.0/24 resides on.

[Porfavor]

192.168.133.0/24 is my LAN subnet, yes. In my (probably wrong) understanding, traffic from e.g. 192.168.133.2, which tries to connect to the internet, goes to the LAN interface of its gateway (OPNsense). As it wants to reach an external address, OPNsense should pass it to its own WAN interface and then to the internet. So the firewall has to allow it to do so. 

The LAN firewall rules (if I am not wrong) allow this. What I might habe forgotten at this point is to allow
source LAN network to destination any at the WAN firewall rules. Or isn't that necessary? That's one direction

Is that correct so far?

[meyergru]

1. If your LAN is 192.168.133.0/24, you need not explicitly name it in your LAN rules as such, but instead, use "LAN Netzwerk" only - and that is there by default for the first LAN. So, the third rule is redundant and should be deleted, because it draws attention to something that does not need to be there,

2. The actual outside access can only work via NAT, yet there are already automatic rules that handle this for "LAN Netzwerk" as well.

3. The 2nd inbound WAN rule (if manually defined by you) would be dangerous, if it worked, which it does not. Because of NAT, you cannot reach RFC1918, such as your LAN from the wider internet, because by definition, RFC1918 addresses are not globally routed. Thus, this rule should be deleted as well - again, if it is not an automatically added rule that was created alongside a corresponding NAT rule.


That set aside, I have no idea, why your LAN clients have no WAN access. In what way are they failing?

Can you ping 8.8.8.8? Can you ping 2600:: ?
Does reolving DNS names like www.google.com work?

See this, #8.

Other than that, depending on what exactly does not work, it can be any of the reasons I outlined in post #3 already, but I would rule out NAT and firewall rules by now.

[Porfavor]

That's what I just mentioned. The third last rule is unnecessary, yes.
Thank you for your consinderations about the second WAN rule. I will disable it.

I cannot ping 8.8.8.8. It's not (only) a DNS issue.

As you can rule out the other two options, I would conclude that is must have something to do with the VPN configuration. I'm just wondering why. Do LAN clients use the tunnel when trying to access 8.8.8. for example? That's not a defined allow IP in the Wireguard configuration. Could it be that I have to limit the wireguard firewall rules explicitely in some way?

I will have a look at your linked thread, otherweise, as soon as I find the time (maybe at the weekend). But it's just so many potential issues that I have got a bit lost.

[meyergru]

It can still be a misconfigured client, like wrong default gateway. You can tcpdump on the interfaces to see if they enter and if and how they exit OpnSense.

[Porfavor]

I am the most stupid anything on earth. If was indeed a misconfiguration of the wireguard peer. That comes, when you don't fully understand things.

I had 0.0.0.0/0 in the allowed IPs of the peer. I wasn't aware of the fact that this would send traffic which does not come from the other end of the tunnel to the wg interface, anyway, or so.

Packet capturing gave me the hint as a ping gave me wg interface entries.

After I removed this, it works, at least.

Thank you for your help.