Shared Forwarding collection

[mimugmail]

To better track down shared forwarding (SF) issues popping up the last days/weeks, I'll create this issue to get a better overview since most of them are here but also one in the forums:

• Broken port forward, works with disabling SF, asked for detailed steps to reproduce https://forum.opnsense.org/index.php?topic=12099.0
• Dual Master cause of "dropped" carp packets when SF is enabled Both virtual CARP IPv6 addresses of the Cluster Machines stay in Master State core#3411 all (2) users report back it works without SF; asked for more details about switches
• IPv6 policy routing not working https://github.com/opnsense/core/issues/3424
• Gateway groups and NAT : Incorrect NAT IP used on interface when Shared Forwarding is enabled core#2376 bit confusing to read, disable sticky session + SF enabled works, sticky session enabled + SF enabled fails (this affects LB setups), sticky session eanbled and SF disabled works. The thread OP just disabled sticky session, this is OK in failover setups

I'll now try to reproduce where possible ... anyone who wants to jump in, very welcome :)
New problem descriptions please in separate issues as this one only collects them.

[mimugmail]

https://github.com/opnsense/core/issues/3424 : Created a HE tunnel at tunnelbroker, followed https://docs.opnsense.org/manual/how-tos/ipv6_tunnelbroker.html and added a policy route for 2a02:2e0:3fe:1001:7777:772e:2:85 via HE gateway. Surfing on www.heise.de (this IP) doesn't go via gif0. After disabling SF and clicking refresh it's travelling via the tunnel.

[fichtner]

Does this work on 18.7 ?

[mimugmail]

https://forum.opnsense.org/index.php?topic=13397.0

[mimugmail]

Today I had a longer phone call with customer:

WAN1, static IP, default gateway
WAN2, static IP, not default

WAN1 IP, port-forward to internal OpenVPN Server
WAN2 IP, port-forward to internal HTTPS ressource

Both WANs have upstream gateway in Interfaces set.

When I have "assiciated rule" in RDR on both rules, OpenVPN is working but HTTPS replies are sent via WAN1 with source IP of WAN2. When I change in RDR for HTTPS the rule association to just "pass" .. it also works for HTTPS. But only as long as the gateway doesn't change.

I haven't tried disabling shared forwarding as it found this little know limitations I tried to collect. Just for refernce I'm working on this again :)

CC @AdSchellevis maybe you also heard similar things from clients? regarding protforwarding on multiple WANs and replies sent over wrong links?

[AdSchellevis]

@mimugmail not that I know of, but combinations with policy based routing can lead to complex scenarios (and issues).

[mimugmail]

note to self: Always check if customer set outbound nat with source as any. This will also nat replys from port forwards and won't be seen in tcpdump when dumping for port 1194 e.g.

Sorry for the noise.

I'll also close this issue as I don't have time to dig deeper into shared forwarding.

Anyone can reopen when it pops up again :)