Hi
I have setup wireguard instance and clients as exactly in this video, it clearly shows
what to do.
However when I connect to the server, it establishes connection but packets are not received.
The only difference is I have pppoe connection (as interface), however I have allowed Wireguard port on the WAN firewall only.
Do I need to open firewall port on pppoe interface rather than WAN? Or how can I trouble shoot? Thanks.
What would be the difference between WAN and pppoe0?
One is just an assigned name for the underlying PPPoE interface - unless you made the mistake of naming the physical NIC (or VLAN) as WAN.
That is the problem with many of those videos: There is no such thing as a step-by-step tutorial, because each situation is different, like your example clearly shows.
You have to understand how things work, otherwise you will be stuck at each crossing.
With a PPPoE connection, you can have one of these topologies on the WAN side:
1. ISP ONT/modem -> physical NIC ("ONT") -> PPPoE interface ("WAN")
2. ISP ONT/modem -> physical NIC ("ONT") -> VLAN ("VLANXX") -> PPPoE interface ("WAN")
With OpnSense, you have either two or three logical interfaces. Name them according to the scheme above. Firewall rules should always be applied to "WAN", which usually is the same thing as "pppoe0". You do not even need explicit names for ONT and VLANXX, unless you want to have direct ONT/modem access. You also do not need firewall rules for "ONT" either, as per default, everything is blocked.
You obviously use it differently, which causes your confusion:
ISP ONT/modem -> physical NIC ("WAN") -> PPPoE interface ("???")
Quote from: meyergru on March 28, 2026, 01:48:45 PMWhat would be the difference between WAN and pppoe0?
One is just an assigned name for the underlying PPPoE interface - unless you made the mistake of naming the physical NIC (or VLAN) as WAN.
That is the problem with many of those videos: There is no such thing as a step-by-step tutorial, because each situation is different, like your example clearly shows.
You have to understand how things work, otherwise you will be stuck at each crossing.
With a PPPoE connection, you can have one of these topologies on the WAN side:
1. ISP ONT/modem -> physical NIC ("ONT") -> PPPoE interface ("WAN")
2. ISP ONT/modem -> physical NIC ("ONT") -> VLAN ("VLANXX") -> PPPoE interface ("WAN")
With OpnSense, you have either two or three logical interfaces. Name them according to the scheme above. Firewall rules should always be applied to "WAN", which usually is the same thing as "pppoe0". You do not even need explicit names for ONT and VLANXX, unless you want to have direct ONT/modem access. You also do not need firewall rules for "ONT" either, as per default, everything is blocked.
You obviously use it differently, which causes your confusion:
ISP ONT/modem -> physical NIC ("WAN") -> PPPoE interface ("???")
Many thanks
I have a very simple setup. No VLANS.
ISP -> PPPoE (WAN) -> LAN Devices
So I did apply the firewall rules to the WAN interface as per the video, so what could be wrong?
Is there a way to check logs or something else that I can identify the problem?
There are two parts of firewall rules (well, actually, it's three):
1. On WAN, you need to allow "in" access on the UDP port that your wireguard instance is running on.
2. On the Wireguard group, you need to create "in" rules to access any of the LAN resources you want external clients to have access to. For starters, you could "allow from any to any".
3. In the wireguard peer, you need to set the "allowed ip" range to those of the wireguard clients that you want to pass. You could use 0.0.0.0/0 here.
All of this is explained for both site-to-site and roadwarrior setups in the official docs (https://docs.opnsense.org/manual/vpnet.html#wireguard).
The order of checks would be outside -> in, so first make sure that the wireguard instance is really contacted by your clients.
That means:
a. the client must be able to connect to your external WAN IP, probably by using its dynamic DNS alias.
b. the client must be allowed to use the wireguard instance's external UDP port.
c. the secrets must be correct, otherwise the packets will be silently discarded.
You can check that via the Wireguard status. It must be green, having a "handshake age" and both sent and received traffic.
The second step would be to verify access from your client to your internal networks.
You can enable firewall logging for the default block rules and watch if there are blocks.
Hi,
Unfortunately I still cannot figure out what I have done wrong
Steps taken as per the road warrior setup:
1) Wireguard Instance created
2) Client peer generated using the peer generator (MTU value is for the PPPoE)
3) Interface assigned
4) Firewall rule has been done for WAN
5) Firewall rule has been done for Interface
6) Normalisation rules have been done as per the guides.
When I am connected to the LAN and turn on wireguard, handshake is done however from outside there is no handshake. I wonder if the firewall does not allow the connection or is there something else? Please see the PDF file attached with the steps showing the screenshots.
I am not sure how to check the logs though, I am new to Opnsense, if you need logs, I will try to provide them.
Obviously your clients cannot connect from outside. That may be because of different reasons, it can even fail before your own WAN firewall rule kicks in, like:
- bad DNS resolution, so that your client cannot find your Wireguard endpoint.
- double NAT setup (router-behind-router), like when your OpnSense is behind an ISP router instead of a bridge modem or ONT.
- your ISP providing CG-NAT only, which essentially is double NAT as well.
Quote from: meyergru on April 08, 2026, 12:06:06 PMObviously your clients cannot connect from outside. That may be because of different reasons, it can even fail before your own WAN firewall rule kicks in, like:
- bad DNS resolution, so that your client cannot find your Wireguard endpoint.
- double NAT setup (router-behind-router), like when your OpnSense is behind an ISP router instead of a bridge modem or ONT.
- your ISP providing CG-NAT only, which essentially is double NAT as well.
Hi,
There is no double NAT. Bridge modem + Opnsense only.
No CG - NAT. I have real IPV4 address if this is what you mean.
What is Bad DNS resolution and how can I troubleshoot it?
And also if you kindly show me how to check the logs for information, will be appreciated.
Your clients must somehow get to your OpnSense, normally this is done via some kind of dynamic DNS update - unless you have static IPs.
The only ways your remote clients know at which IP they must direct their WG VPN packets to are:
1. Static IPs.
2. A DNS entry that can be resolved and points at whatever IP your OpnSense has at the time, especially with dynamic IPs. It is this entry that must be present in the client configuration - and AFAIK, it is not automatically included in the peer configuration that OpnSense generates.
So, you must create and upkeep a DNS name under which your OpnSense can be reached - at least if your WAN IP address changes at times. Also, when the connection drops, the connection must be re-initiated by the client, potentially with the same DNS entry now pointing to another IP adress.
If the connection is not created at all, logs will not help you. You can try to do a tcpdump on the WAN interface in order to see if packets on the Wireguard target port even reach your OpnSense. If that is the case, you can try to enable logging for dropped packets and find out why they are blocked.
Hi,
I have static IP so no need for Dynamic DNS etc..
I think I will give up. It simply doesn't work. Should not be this difficult. And for the note I believe Opnsense is quite buggy in Wireguard (especially for peer generator). Anyway I won't go into the details much. Please see the firewall log which I could get, the packets simply being discarded for the reason I don't understand.
Please show the firewall rule you created that is supposed to let WireGuard connections in on your WAN interface.
Also:
Quote from: leony on April 08, 2026, 11:41:12 AMMTU value is for the PPPoE
You have to deduct something for the VPN header overhead from your actual MTU, you know that?
Also, Patrick is right: That blocked packet clearly shows that the default deny rule applies, so whatever rule is supposed to allow that VPN traffic seems to be incorrect.
Please see attached. I am having trouble adding peer though using peer generator. Without presssing store text, it never saves (but it is already ticked). When I press, the keys change. When I finally save, endpoint info does not appear on the peer, which I need to add manually again. Not sure if these are known bugs for version 26.1.2
I have also created normalisation rule for Wireguard (Group) as per the document, if you need to me to attach it as well, please let me know, thank you.
And there you have it: Your WAN rule has source and destination reversed.
Quote from: leony on April 09, 2026, 10:30:02 AMPlease see attached. I am having trouble adding peer though using peer generator. Without presssing store text, it never saves (but it is already ticked). When I press, the keys change. When I finally save, endpoint info does not appear on the peer, which I need to add manually again. Not sure if these are known bugs for version 26.1.2
It's probably not a bug, the User Interface of the Peer generator is just plain terrible and counterintuitive.
QuoteWhen I am connected to the LAN and turn on wireguard, handshake is done however from outside there is no handshake.
Are you trying to connect to the WireGuard while the client is inside the local LAN or from an external network?
Have you tried lowering the MTU as meyergru suggested?
Disabling/reenabling WireGuard?
EDIT: meyergru is right, you have the source/destination reversed in the latest screenshot compared to your initial PDF.
Sorry I was playing around with the Firewall, realised it was a mistake in the source and destination.
MTU was lowered yes.
Disabled/enabled instance and the device was rebooted.
Generally I tested to log from external network.
I will get another firewall, different location and try again, if this also does not work, it is probably either me or there are real problems with wireguard setup with Opnsense. I am not sure how others make this work, as you said adding peer is a very painful process, it is possible that I may have done something wrong with the peer configuration files.
Ps: Is Open VPN setup a less painful process? Any guides? I have a very simple setup as you have seen from the images, all I want is to have VPN access to the local network and connect to the internet as well once VPN is established.
Adding a peer is in my experience completely painless. Comfigure the peer in the peer's UI, e.g. WG for Mac OS, copy and paste public key into OPNsense peer settings, done. I never used this peer generator thing.
Doing it manually is probably the best option.
Quote from: leony on April 09, 2026, 11:20:22 AMPs: Is Open VPN setup a less painful process? Any guides? I have a very simple setup as you have seen from the images, all I want is to have VPN access to the local network and connect to the internet as well once VPN is established.
I had no previous experience with WireGuard before setting it up in OPNsense and have managed to set up both S2S and Road Warrior links without much issue. It's not the most intuitive process in some cases, but it shouldn't be too much of a problem. You're probably 90% there and just missing some crucial step.
I would delete the current WG config and follow this guide: https://homenetworkguy.com/how-to/configure-wireguard-opnsense/
Thanks I will figure out somehow to do trial and errors. Hopefully will get there.
Finally can you please advise if adding peer in attached way is correct? I won't use the peer generator. I am a bit confused particularly with Public Key and Allowed IPs (Peer Generator and manual adding seem to be a bit different to me)
Edit Peer:
Public key - you can use the one from the generator but just copy&paste it manually
Allowed IPs - 10.10.10.4/32 (peer address)
Endpoint Address - leave empty (set on the client/peer instance, not in OPNsense)
Endpoint port - leave empty (set on the client/peer instance, not in OPNsense)
Keepalive - leave empty (set on the client/peer instance, not in OPNsense)
I have finally resolved the problem. The answer was my original question. Shall the firewall rules be applied to the WAN or PPPoE Interface?
I have removed the WAN firewall entry and added the same to the PPPoE Interface and that did the trick.
To all having the same problem, this is the answer. Many thanks
You should have assigned WAN to the PPPoE interface. PPPoE and WAN are supposed to be one and the same thing if your uplink works via PPPoE.
Quote from: Patrick M. Hausen on April 11, 2026, 05:57:21 PMYou should have assigned WAN to the PPPoE interface. PPPoE and WAN are supposed to be one and the same thing if your uplink works via PPPoE.
You are right, the problem was the interface assignments and in return wrong firewall entries.
All good now thanks for your help.