We have a wireguard tunnel set up and we are having no issues accessing any of the devices on the default network. However, we cannot access any of the on the vlan interface subnets. There are no firewall rules on the subnet interfaces preventing traffic from reaching the Wireguard networks. The only rule on the Wireguard interface is the default allow all rule. And the client peers have the corresponding networks added in the AllowedIPs section. We have tried everything we can think of and have not been successful. Can anyone provide some possible solutions?
I am not sure what information to post to help diagnose the issue so if there is any information you would like to see to assist us in figuring this out, please let me know.
A common issue and first thing to check is for the allowed IP’s and make sure you have 172.16.16.0/24 and not 172.16.16.1/32 so you have the entire routable subnet. Also check to make sure the routing table on each site has the entries for the networks you want routed.
This is a Debian system connecting to pfSense. These are the results produces when the tunnel is brought up:
[#] ip link add office type wireguard
[#] wg setconf office /dev/fd/63
[#] ip -4 address add 172.17.1.7/24 dev office
[#] ip link set mtu 1420 up dev office
[#] ip -4 route add 10.0.5.0/24 dev office
[#] ip -4 route add 10.0.10.0/24 dev office
[#] ip -4 route add 10.0.1.0/24 dev office
Based on this I assume the routes are being created on the workstation side.
I am able to ping 10.0.5.1, and 10.0.10.1. Just not any of the devices on the subnets.
Something else to check is making sure the hosts behind pfsense have routes back to reply. At about the 10 minute mark I cover setting up the static routes for that.
Thanks for the follow up. I’m not sure I understand. This is not a site to site implementation. This is a single host creating a tunnel to a psfense gateway with the goal of accessing the various networks behind the gateway. At this point the tunnel has not been configured as an interface or gateway. Therefor no static route has been created to route 172.17.1.0/24 back through the tunnel. However, I do have an outbound NAT rule set up to send tunneled traffic out the WAN for full tunnel use cases. I reviewed your video on “pfsense Wireguard For Remote Access” and it seems the steps we completed match those of the video.
It’s been a while since I have used pfsense and Wiregaurd as anything other than a site to site setup. For users connecting we generally use OpenVPN. I will check later if I have any notes from my older video on the topic.
I reviewed the documentation and found information on “Finding the rule which caused a log entry”
In ran the following command:
pfctl -vvsr | grep 1000005670
The results: @83 block drop in log on ! ix0.10 inet from 10.0.10.0/24 to any ridentifier 1000005670 @84 block drop in log inet from 10.0.10.1 to any ridentifier 1000005670 @85 block drop in log on ix0.10 inet6 from fe80::225:90ff:fee0:802a to any ridentifier 1000005670
I would agree with Tom here. Please check that your normal routing tables allow the packets to come back to the client.
I have troubleshooted this kind of problems many times, and the most common problem is the routing.
If you can tcpdump on the wg interface and see what packets are entering and exiting the wg interface, this normally helps you to understand where the problem is.
I also use WireGuard for site-to-site and road warrior-to-site communications. And I have found Wireguard more stable, well performing and easy to setup than my old IPsec tunnels.
Since it is coming from your Manangement interface check the firewall rules there. Hover over the States fields and you will see tracking id which should be the ridentifier. This way you can see what rule to correct.
