Port forwarding through WG tunnel missing reply-to

viragomann

@Bronko said in Port forwarding through WG tunnel missing reply-to:

Allow any rules on both wg_interfaces and on lan_seite3 interface in place

To ensure that the proper firewall rule is applied to the incoming traffic, at site B state a unique description for rule on the specific tun_wg0 interface.
Then try a connection to the server from outside and check in the firewall log after if the rule is shown up.

Bronko

@viragomann

Log packets matched from the default block and pass rules in the ruleset are enabled in general logging options too.
(newest entries on top)

Screenshot from 2023-10-09 01-12-47.png

With "workaround" (outbound rule on Site-A active):
Screenshot from 2023-10-09 01-14-48.png

/root: pfctl -vvsr | grep 1673389761
@103 pass in log quick on tun_wg0 inet all flags S/SA keep state label "USER_RULE: WG_seite3 allow any" label "id:1673389761" ridentifier 1673389761
/root: pfctl -vvsr | grep 1000019363
@64 pass out log inet all flags S/SA keep state allow-opts label "let out anything IPv4 from firewall host itself" ridentifier 1000019363
/root: pfctl -vvsr | grep 1696805920
@104 pass in log quick on re2.301 inet all flags S/SA keep state label "USER_RULE: LAN_seite3 allow any" label "id:1696805920" ridentifier 1696805920

viragomann

@Bronko
So obviously there is a floating rule with the label "let out anything IPv4 from firewall host itself" passing the traffic. This might end up in none reply-to tagging.

Bronko

@viragomann

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 1000019363

Where can I find this rule? Ridentifier looks like something default?

viragomann

@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.

Bronko

@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)

Bronko

@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!

Screenshot from 2023-10-09 19-14-18.png

Real Links:

WAN to WireGuard to LAN reply-to bug
Bug report
WAN vs LAN Interfaces -> VPN Interfaces

viragomann

@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.

Bronko

@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?

viragomann

@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 wrote

Rules on assigned interface tabs get reply-to which ensures return routing will exit back the expected interface for inbound connections.

Bronko

@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!

viragomann

@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.

Bronko

@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...

viragomann

@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.