[Solved] Client subnet not accessible (and no internet)
-
@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!!
-
@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.
-
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!
-
@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
-
@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!
-
@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!
-
@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.
-
@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!!!
-
@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.
-
@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!!!
-
@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!
-
@arrmo
NAT for OW LAN subnet to WAN means to allow OW LAN to browse internet so that is correct. -
@ab5g Excellent, thanks! "Interface" in this case was just a bit confusing.
Thanks again for all the help and pointers!!
-
@arrmo FYI, opening a new question - all working well, except one type of traffic. Huh?!?! LOL!
-
@arrmo you can edit the original post and mark this solved
-
@ab5g Will do, thanks!
