Wireguard VPN

[leony]

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.

[meyergru]

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 ("???")

[leony]

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 ("???")

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?

[meyergru]

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.



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.

[leony]

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.

[meyergru]

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.

[leony]

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.

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.

[meyergru]

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.

[leony]

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.

[Patrick M. Hausen]

Please show the firewall rule you created that is supposed to let WireGuard connections in on your WAN interface.