Bug #12530
closed
wireguard 0.15 bypasses firewall
0%
Description
I created a tunnel not assigning an interface and only defining the IP on the same page (interface address) but notice that the UDP port 51820 is exposed in the WAN interface I thought that port 51820 needed a WAN rule but that seems not to be the case.
If I create more tunnels more ports become open/exposed 51821, 51822, etc
If using OpenVPN for example I need to explicitly define the port in the WAN interface otherwise is not reachable, but it is not the case for wireguard.
Also is there a way to pass extra parameters like for example Table = off
Updated by Jim Pingle over 2 years ago
- Project changed from pfSense to pfSense Packages
- Category changed from WireGuard to WireGuard
- Assignee set to Christian McDonald
- Release Notes deleted (
Default)
Updated by Christian McDonald over 2 years ago
Without an UDP allow rule on WAN, my remote peers are not able to initiate a connection.
The key here is 'initiate.'
As long as one peer can initiate a handshake and establish a UDP path, this same path can be used to ride back in from the remote peer. The confusion here is WireGuard has no concept of Server and Client, they are peers.
This behavior might be worth noting in the docs, but it is expected.
As for Table = off, that is a wg-quick feature and we are not using wg-quick internally for tunnel management. We do everything with the lower-level wg(8) command and use pfSense's built-in glue for handling routes.
Perform your testing again under this assumption. If a remote peer can initiate a connection without an allow rule on WAN, that would be a concern.
Updated by Christian McDonald over 2 years ago
- Status changed from New to Rejected
Updated by Nicolas Embriz over 2 years ago
Christian McDonald wrote in #note-2:
As long as one peer can initiate a handshake and establish a UDP path, this same path can be used to ride back in from the remote peer. The confusion here is WireGuard has no concept of Server and Client, they are peers.
Thanks for the clarification that is indeed what I notice
Updated by Jim Pingle over 2 years ago
If your peers use a static port on both sides and initiate A->B and then immediately stop/start WG and try B->A this will work because the state table entry for the IP:Port on both ends is still there allowing traffic. This time span depends on your state table optimization/timeout settings but is typically 30s.
For a proper test you must clear/reset the states between connection attempts.
If that still works, you have a rule somewhere passing the traffic. Post on the forum for assistance in that case.