Port forwarding does not always work as expected?

[tkald]

This is strange one ...

Having trouble getting data back from some port forwarding rules - for example from haproxy (on linux host) in "dmz zone" on lan. For example on the same haproxy host, second frontend with tcp mode works. But one with http mode does not. Both http and tcp frontends are pointed to the same backend server. It works fine from other routed network from "inside". It also works from outside it I forward port directly to apache server (leaving haproxy out). Both port 80 and 443 forwardings are done in one rule with port aliases as destinations, so I assume it can't be misconfiguration (tried also with separate forwarding rules). From wan side, it sends back some packets though (I get correct page title on the browser), then tcp retransmissions start. Tcp dump from haproxy host.

Second wierd example - one host with old zabbix-agent on the internet stopped sending data (through port forwarding) after I moved to Opnsense (was pure freebsd previously). Restarted zabbix-agent several times with no success. After not altering any opnsense configuration I upgraded zabbix-agent software to the latest version and data sending resumed.

I do have v17.1.1 Opnsense on two node HA setup with dual wans (active/backup), multiple carp virtual ip-s on top of vlans on top of lagg-ed interfaces :) Port forwarding is done on both wan interfaces, same behaviour on both. Manual outbound nat rules.

Any thoughts/suggestions?

[tkald]

OK, figured it out! It's "option httpclose" in haproxy configuration which does not cooperate with my Opnsense setup. Removed it and problem solved :)

[tkald]

More similar issues, this time without network translation on Opnsense side. Over vpn link, client with routed network sends different data to server(s) in opnsense lan nework. One data stream of four ends up in retrasmission loop:

Its Unifi wifi access point sending data to controller.

However another access point (same model) over another vpn link sends data just fine.

[djGrrr]

Try running this command in shell / console as root: sysctl net.pf.share_forward=0

Then see if there is any change

[tkald]

Yes @djGrrr , it does reslove my last issue.

[fichtner]

We're going to set net.pf.share_forward=0 on 17.1.2 by default. Ready to close?

[tkald]

yes

[fichtner]

Ok, thank you 😊

[tkald]

I found that there's still some issues with port forwarding with _sysctl net.pf.shareforward=0 on v17.1.2 L7 traffic responses on haproxy on linux box in "DMZ" zone on certain cases don't respond correctrly to "outside" requests. For example if I send header redirect to client.

frontend web
mode http
bind :80
option http-server-close
acl host_old hdr_dom(host) -i www.old.url
http-request redirect location http://www.new.url code 301 if host_old

It works from lan, but not to clients accessing server from wan. From wan, client can open 80 port, but no response. Pretty much as described in first post.