[Solved] Client subnet not accessible (and no internet)

arrmo

@ab5g said in Client subnet not accessible (and no internet):

System > Routing > Gateways > Set that to WAN_DHCP (or whatever your gateway is) ; don't leave that to automatic.

It is set to automatic, but there is only one option (WAN_DHCP) ... and that one shows the world symbol. So OK, agreed?

@ab5g said in Client subnet not accessible (and no internet):

If that doesn't work, you'll need to provide more info

OpenWrt Side - LAN 192.168.0.1/24, Tunnel IP. 192.168.253.3 , Test PC - 192.168.0.220
pfSense Side - LAN ? , Tunnel IP 192.168.253.1 , Test PC - ?
Routing tables, and wireguard config

Absolutely! Let me try to clarify - yell if this is not clear.

pfSense - subnet is 192.168.2.x, WAN (to cable modem) is 192.168.1.x.
OpenWrt - subnet is 192.168.0.x. I can get to the internet from ssh (I think it comes from the WG address then?), but not from machines on the .0.x subnet. That's the core issue, .0.x machines not being able to get out. But they can get to machines on the .2.x (pfSense) subnet. Make sense?

AllowedIP's, for WG

pfSense: 192.168.253.3/32, 192.168.0.0/24
OpenWrt: 192.168.253.0/24, 216.115.184.69/32, 192.168.1.0/24, 192.168.2.0/24, 192.168.0.0/24 (last one seems to be needed to get ping from OpenWrt to pfSense to work?).

I also can't get from the pfSense subnet (..2.x) to OpenWrt subnet (.0.x).

Thoughts?

Thanks!

AB5G

@arrmo
Let's tackle it one by one. First off "can't get from the pfSense subnet (..2.x) to OpenWrt subnet (.0.x)."

Thats because there's only 1 gateway in your pfsense which is the WAN_DHCP and so all packets coming from pf LAN are being sent out through that GW. The GW doesn't know how to route them so it doesn't work. To solve this, you need to create a gateway (corresponding to wireguard tunnel) and route packets destined to 192.168.0.0/24 to that gateway. Makes sense ?

To create the GW, you need to create the interface first. After the WG tunnel comes up, you need to goto Interface/Assignments and assign wg0 (the tunnel) a new Interface say "WG". Enable the interface and restart the tunnel. This should create the GW for you (System > Routing > Gateways).
Now select WAN_DHCP as your default gateway. Don't leave that to auto.

Next, you'll notice that the under firewall you'll see the interface entry for 'WG'. To keep things simple. Put a rule Allow any proto from src WG net to any dest. This will allow any inbound traffic coming from OpenWrt to reach your pf LAN.

Finally to allow pfLAN to reach OW LAN - create a LAN rule - proto any, src LAN net, dest 192.168.0.0/24 , advanced, set gateway to WG_GW.

arrmo

@ab5g I THINK this is working . Just a bit worried yet, I have fooled myself before - but cautiously optimistic. Let me roll with it for a day or two, see if it really is solid. It didn't seem to work initially, but did after I made some other WG changes ... so perhaps also needed a WG (interface) restart of sorts? I admit, not quite sure how to force that to happen (reloading and taking the interface down and back up I assume)?

Thanks for the pointers!

jimp

@arrmo said in Client subnet not accessible (and no internet):

I admit, not quite sure how to force that to happen

To refresh the WireGuard interface config, edit the WireGuard tunnel on VPN > WireGuard and save it there. That will redo the interface config and so on.

arrmo

@jimp said in Client subnet not accessible (and no internet):

To refresh the WireGuard interface config, edit the WireGuard tunnel on VPN > WireGuard and save it there. That will redo the interface config and so on.

Perfect, thanks! I assume this is similar to / the same as ifdown then ifup? Was thinking there may be a button on the main screen, but definitely not a biggie

Thanks again.

arrmo

@ab5g said in Client subnet not accessible (and no internet):

Let's tackle it one by one. First off "can't get from the pfSense subnet (..2.x) to OpenWrt subnet (.0.x)."

OK, this one seems solid - so far at least . Thanks again, really appreciate it!

So the one that is open yet - I can't seem to get from the OpenWrt subnet (.0.x) out to the internet. No issue getting to the pfSense subnet (.2.x), but from there ... I can't get "out the door". I can get from the OpenWrt "console" itself (to the internet), but pretty sure that's showing a source address of .253.3 (i.e. WG address). Where it falls down is coming from .0.x, trying to get out the Gateway (on pfSense). Perhaps a routing setting that is missing? Or because .0.x is being routed back to OpenWrt, vs. out the door?

Thanks!

AB5G

@arrmo

For the second one, you'd need a NAT rule. The packets from OW LAN are Natted by OpenWrt to 192.168.253.3/32 and sent to pf WG interface. The interface FW rule is set to allow WG NET (192.168.253.0/24) to any > which means the traffic can now enter and therefore you can reach the pf LAN. To exit using the internet at pf site, you'd need to tell pf to allow the 192.168.253.0/24 (WG NET) to be natted to the WAN interface IP to exit.
Goto firewall > NAT > Manual Outbound > Create new > Int WAN > Src 192.168.253.0/24 > src port any dest any destport any, NAT address WAN address.
Save and restart the wireguard tunnel.

arrmo

@ab5g said in Client subnet not accessible (and no internet):

Goto firewall > NAT > Manual Outbound > Create new > Int WAN > Src 192.168.253.0/24 > src port any dest any destport any, NAT address WAN address.
Save and restart the wireguard tunnel.

Thanks! Tried that, but I don't think it's working (may be me though!). Here is the rule I created,

And the auto one that also already exists (second one)?

But, watching tcpdump across the WG interface, I get this for a ping (and no response ... traffic coming across from OpenWrt subnet),

20:34:04.690815 IP 192.168.0.243 > 216.115.184.69: ICMP echo request, id 1, seq 441, length 40
20:34:09.327358 IP 192.168.0.243 > 216.115.184.69: ICMP echo request, id 1, seq 442, length 40

I did try changing the NAT rule you mentioned, to .0.0/24, but no joy still.

Thoughts?

Thanks!!!

AB5G

@arrmo
You should not see packets coming from 192.168.0.243 on pf. You should be natting OW LAN to 192.168.253.3/32 on the OpenWrt box. With this your NAT rule of 192.168.253.0/24 will work.

In case you do not want to NAT on the OpenWrt side then on the WG interface (firewall rules) in pf you need to allow 192.168.0.0/24 segment (right now you are only allowing 192.168.253.0/24 segment). Then you'd need a NAT rule for 192.168.0.0/24.

Don't forget to restart the tunnel after the NAT rule change

arrmo

@ab5g said in Client subnet not accessible (and no internet):

In case you do not want to NAT on the OpenWrt side then on the WG interface (firewall rules) in pf you need to allow 192.168.0.0/24 segment (right now you are only allowing 192.168.253.0/24 segment). Then you'd need a NAT rule for 192.168.0.0/24.

That makes sense - thanks! It seems like the interfaces all get auto-rules generated (even in Manual mode) ... is that right? But as you say, I'll add the .0.x rule, see if I get that working correctly.

BTW, I seem to have a rule for "Wireguard" (group?) - thinking that was from different things I was trying. Assuming that's not needed (i.e. no rules under that Group), right?

Thanks again!!

AB5G

@arrmo said in Client subnet not accessible (and no internet):

It seems like the interfaces all get auto-rules generated (even in Manual mode) ... is that right?

Yes

"Wireguard" (group?)

Yeah you can ignore that - create all rules under WG Interface that you created.

arrmo

Perfect, that makes sense (auto rules to manual list). Thanks!

@ab5g said in Client subnet not accessible (and no internet):

Yeah you can ignore that - create all rules under WG Interface that you created.

Well ... . I did that, and broke things as a result. Still trying to wrap my head around it, but I seem to need the WireGuard (tunnel / group?) rule in place. I was thinking that something wasn't getting through the WG (interface) rule, but it may not be getting there perhaps? It's not quite clear to my why yet, sorry! What's also interesting ... with both rules in place, I only see states showing up in WireGuard (tunnel), not WG (interface) ... is that because somehow once the tunnel passes it the interface doesn't see it?

Sorry, just a bit confused yet. But that's my head, I know .

Thanks!

AB5G

@arrmo At this point I would suggest you read the documentation along with the contents of my post to get a grasp on what's happening.

From the documentation "Use rules on the WireGuard group tab or rule tabs for assigned interfaces.
Rules on the WireGuard group tab are considered first and can match traffic on any WireGuard interfaces whether or not they are assigned."

So if you have already assigned an interface (WG), you don't need additional rules in the WIREGUARD group tab.

https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/rules.html

arrmo

@ab5g said in Client subnet not accessible (and no internet):

So if you have already assigned an interface (WG), you don't need additional rules in the WIREGUARD group tab.

Yes, 100% agreed! And this is the way I understood your comment as well. But I have the interface assigned (like you said above), and rules on that interface. But, if I don't (also) add a rule on the WIREGROUP group tab - traffic is not getting through. That's where I get confused. Thinking that should not be required, exactly as you say.

On the interface tab, I have two rules ... to pass traffic from source "WG net", also "192.168.0.0/24". So very surprised that's not sufficient.

Thanks!

arrmo

@ab5g said in Client subnet not accessible (and no internet):

https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/rules.html

OK, been reading through the pfSense docs, and the configuration I have set up (matching your comments above). Funny, but I found the page you note as a very key one as well - agree with you! And the settings you noted do make sense to me (now ), they all seem logical and right. I admit, I'm impressed how well you knew those.

That said, pulling my hair out . The best I can tell (and from that page), rules are allowed on the "WireGuard group tab", and they are processed first. But if no rules are there, then the "WireGuard interfaces" are considered (and I assume that once traffic is marked as pass by the group tab, the interface rules are skipped ... right?). That all said, if I turn off the "pass all" rule I have on the group tab, traffic from the remote (OpenWrt) subnet doesn't get through (to the internet). With the rule on, I see states and traffic counting on the group tab, and nothing counting on the WG interface tab (again, seems like it gets skipped). But, if I remove the rule on the group tab ... yep, traffic isn't getting through (and yes, restarting WG each change).

Does this make sense to you? It's likely me, but it's not making sense. And it seems to only be an issue with traffic from that subnet (yet there is a rule on the interface tab for that subnet). Dang it!

Thanks!

AB5G

@arrmo It should work without the rules in the Wireguard group tab.
https://docs.netgate.com/pfsense/en/latest/vpn/wireguard/rules.html#tunneled-traffic

"Rules on the WireGuard group tab are matched first, so ensure rules on the group tab are removed, disabled, or do not match traffic which requires reply-to."

"Rules on assigned WireGuard interface tabs also get reply-to which ensures that traffic entering a specific assigned WireGuard interface exits back out the same interface. Without that, return traffic will follow the default gateway."

In your case , you need the traffic to not hit the default GW which is WAN_DHCP and therefore you need the 'reply-to' address. So all your rules should be in the WG interface tab and not the Wireguard group tab. If you have rules in the Wireguard group tab, it will not match any in the WG tab (which you need it to).

Now on the reason why WG int rules are not working, could be a NAT issues - do you have a NAT rule in place natting WG int to WAN (for internet breakout). Use hybrid outbound as a NAT rule and add WG int to WAN selecting the correct subnet. You can start with a clean configuration of Wireguard and try again.

arrmo

@ab5g said in Client subnet not accessible (and no internet):

"Rules on the WireGuard group tab are matched first, so ensure rules on the group tab are removed, disabled, or do not match traffic which requires reply-to."

Thanks! I had seen that, wasn't sure I fully followed it ... LOL! What's odd is that this rule (group tab) works, not the interface - seems reversed, no? Or did I misunderstand your / the point?

@ab5g said in Client subnet not accessible (and no internet):

Now on the reason why WG int rules are not working, could be a NAT issues - do you have a NAT rule in place natting WG int to WAN (for internet breakout). Use hybrid outbound as a NAT rule and add WG int to WAN selecting the correct subnet. You can start with a clean configuration of Wireguard and try again.

I have the rule we discussed above - though I may have it wrong . It's that OpenWrt subnet, NAT'd to WAN, like you say. Will try clean, that makes a lot of sense! To understand ... WG int => NAT the full interface (so both rules there feed it), to WAN. Did I get your point right? Meaning ... not just the OpenWrt subnet, as I have now, but rather the WG int, correct? Actually, looking at the NAT options, I can't select the interface as a NAT source (or does that change when using Hybrid?).

Thanks again for the pointers!!!

AB5G

@arrmo
'seems reversed, no?' - Yep it is reversed. You should only have rules in WG int and not Wireguard Group.

For NAT there are 2 options - I don't know which one you are using. Are you Natting all OW LAN to the tunnel IP at the OW side ?

Refer to my comment from before -

You should be natting OW LAN to 192.168.253.3/32 on the OpenWrt box. With this your NAT rule of 192.168.253.0/24 will work.

In case you do not want to NAT on the OpenWrt side then on the WG interface (firewall rules) in pf you need to allow 192.168.0.0/24 segment (right now you are only allowing 192.168.253.0/24 segment). Then you'd need a NAT rule for 192.168.0.0/24.

arrmo

@ab5g Yep, all makes sense. I think part of this may be that it seems restarting WG on pfSense is not enough ... I seem to need to also reset / reboot on OpenWrt, after pfSense changes. Let me try the changes ... will fiddle for a bit, get back to you.

Thanks!!!

arrmo

@ab5g said in Client subnet not accessible (and no internet):

In case you do not want to NAT on the OpenWrt side then on the WG interface (firewall rules) in pf you need to allow 192.168.0.0/24 segment (right now you are only allowing 192.168.253.0/24 segment). Then you'd need a NAT rule for 192.168.0.0/24.

It's working! The issue was after (firewall / rule) changes, really having to reset / reboot both ends. That was fooling me a bit. To your point, NAT on the OpenWrt side is more difficult, only because it's 1800 miles away ... so if I mess something up, I can't really manually reboot it very easily. So NAT on pfSense (which I sit beside ) is much easier.

That all said, I did have both rules already in the interface. And I am NAT'ing (manually) from the OpenWrt subnet - which works. The only minor thing is that I noticed (after I created the Outbound NAT), that I have the interface set to WAN. It seems to work, but should that interface be WG instead? Or does it matter / apply?

Thanks again!