Port forwarding through WG tunnel missing reply-to
-
But it's nothing in the WebGUI Tab for Floating rules...
/root: pfctl -sr |grep 1000019363 pass out log inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself" ridentifier 1000019363Where can I find this rule? Ridentifier looks like something default?
-
@Bronko
It's not clear to me, why this rule matches to the traffic from remote, since the source is not the firewall itself. But since it matches, it might create a state with no gateway defined.I guess, it's caused by the setting System > Advanced> Firewall & NAT> Disable Negate rules.
If you check this, you might have to create some extra rule to pass desired traffic. -
@viragomann said in Port forwarding through WG tunnel missing reply-to:
I guess, it's caused by the setting System > Advanced> Firewall & NAT> Disable Negate rules.
If you check this, you might have to create some extra rule to pass desired traffic.Checked (enabled), but rule is still present and catched the traffic as before...
(at Site-A - fresh 2.7.0 installation - this rule is present too; Site-B: 2.6->2.7 upgrade) -
B Bronko referenced this topic on
-
@viragomann Don't know why, but can't post this because of "Post content marked as Spam by Akismet.com", so picture from Preview... Smiley!
Real Links:
WAN to WireGuard to LAN reply-to bug
Bug report
WAN vs LAN Interfaces -> VPN Interfaces -
@Bronko
So stating an IP and a gateway in the wg interface settings was part of the solution or did you that before already?
I don't expect, that this is necessary normally for a Wireguard site2site connection. Yes, this adds an outbound NAT rule. -
@viragomann said in Port forwarding through WG tunnel missing reply-to:
So stating an IP and a gateway in the wg interface settings was part of the solution or did you that before already?
Stating an IP in the wg interface and the gateway itself was there before (official doc).
(I did it to have it for policy routing to route outbound traffic from machineMX over Site-A: sending email.)
Choose these gateway as upstream gateway in wg interface was the first step of solution...@viragomann said in Port forwarding through WG tunnel missing reply-to:
Yes, this adds an outbound NAT rule.
... to neutralize this by Do not NAT rule was the final step.
@viragomann said in Port forwarding through WG tunnel missing reply-to:
I don't expect, that this is necessary normally for a Wireguard site2site connection.
That's why we should call this a bug?
-
@Bronko said in Port forwarding through WG tunnel missing reply-to:
Stating an IP in the wg interface and the gateway itself was there before (official doc).
Indeed, you're right.
I configured a Wireguard site2site once in the past, but didn't recall to state IPs and gateways in the interface settings, even I assigned interfaces to the instances.
However, I replaced it soon with an IPSec tunnel due to incompatibility with HA. So didn't gain considerable experience with it.I don't expect, that this is necessary normally for a Wireguard site2site connection.
That's why we should call this a bug?
At least it's odd. The need of stating an IP and a gateway in the WG interface settings to enable the reply-to isn't mentioned in the Wireguard section of the docs, but only in the configuration recipes section you've quoted.
In Assign a WireGuard Interface they just wroteRules on assigned interface tabs get reply-to which ensures return routing will exit back the expected interface for inbound connections.
-
@viragomann said in Port forwarding through WG tunnel missing reply-to:
Rules on assigned interface tabs get reply-to which ensures return routing will exit back the expected interface for inbound connections.
You are right with this quote, but without a defined gateway on assigned interface too, in the/our real world it doesn't seem to work.
That's why @carrnelltech report these possible bug in the right manner:
I have discovered that the WireGuard package requires the interface to have the gateway set for the reply-to rules to function as expected. However, this also creates an undesired auto NAT rules that need to be manually disabled in order to use the reply-to rules effectively.
May be netgate find it worth to check our two independent reports...
@viragomann Thank you so much so far!
-
@Bronko said in Port forwarding through WG tunnel missing reply-to:
You are right with this quote, but without a defined gateway on assigned interface too, in the/our real world it doesn't seem to work.
That's why @carrnelltech report these possible bug in the right manner:
For ordinary (none VPN) interfaces it's a normal behavior, that there must be a gateway defined on the interface for enabling reply-to. This can be done either manually by stating an IP and a gateway, or automatically via DHCP or PPP.
However, if you assign an interface to an OpenVPN instance, you must not manually configure an IP / gateway. It is set automatically by OpenVPN. In resent versions, the IP configuration is actually disabled.
I assumed, that it behaves in the same way with Wireguard, but obviously it doesn't.So I wouldn't consider it as a bug to be honest, it just needs a different configuration.
But I agree, this should be mentioned clearly in docs though. -
@viragomann said in Port forwarding through WG tunnel missing reply-to:
However, if you assign an interface to an OpenVPN instance, you must not manually configure an IP / gateway. It is set automatically by OpenVPN. In resent versions, the IP configuration is actually disabled.
Yes, the IP configuration isn't present at OpenVPN interface configuration and the automatic generated gateway is fixed to dynamic.
@viragomann said in Port forwarding through WG tunnel missing reply-to:
So I wouldn't consider it as a bug to be honest, it just needs a different configuration.
But I agree, this should be mentioned clearly in docs though.Ok, but @carrnelltech have the right ideas already included at bug report.
And to bee honest, I'm not a deep diver here...
-
@Bronko said in Port forwarding through WG tunnel missing reply-to:
Ok, but @carrnelltech have the right ideas already included at bug report.
Yes, agree, he elaborated this bug report very well. Similar as the interface config page for OpenVPN, there could be some different options if you have assigned a Wireguard instance as network port.