@macaruchi
All clear now.

I see this issue:
On the ISP router, you forwarded traffic on port 8443 to <pfSenseWAN2>:443
On pfSense forwarded traffic from WAN2:8843 to <weberver>:443

But pfSense doesn't get the packets on port 8443, but on 443. So you need to change the destination port in the forwarding to 443.

You should also change the WebGUI port to anything else. You can do this in System > Administration.

@netgatecustomer2485 said in 4100 LAN[234] setup problems:

I read the manual a bit more

I'll save you the trip to the manual.
LAN[234] will reply your pings if you allow it to do so. Typically : use a firewall rule on LAN[234] that let ICMP pass.

Bridge : on a 4+2 port 4100 ?
The non technical solution : get an inexpensive 5 port 1Gb switch. True : this will consume about 8 W x 24 x 365 = 70 Kwh per year, that nearly 4 € or 4 $ a year.
This will make maintenance live easy on you.

@StefanKittel said in How to multi-forward with multi WAN?:

I have a current pfsense running with about 12 WAN-lines

Wow! (?)

Can I forward all ports for each WAN-interface (12 rules) to a virtuel interface and from there to each client (40 rules)?
That would be much easierer.

No, not this way that the virtual IP is on pfSense. Port Forwarding is applied at first step on incoming packets on an interface. So if the packet doesn't enter an interface, no port forwarding rule is applied at all.

Refer Ordering of NAT and Firewall Processing

What you could do to simplify the rules is proxying the traffic using HAproxy.
So you can configure frontends (maybe TCP mode), one for each port, listening on any IP, say localhost. And forward traffic from all interfaces to localhost.
You will need a separate rule for each not continuous port range though, however, it should be possible to do this with a single rule for each port on interface groups (all WANs).

But I'm not sure if this will also work in transparent mode, otherwise you will lose client information of none-http traffic.

IPPBX needs to connect to to upstream SIP Trunk provider. Outbound SIP calls work fine. Inbound does not traverse (initiated at the Trunk Provider) Starlink and fail.

The solution is to provide a VPN. I have a dedicated server running ProxMox in a data center and enough IPs to provide the VPN connection.

My thought is to provide a VPN to a pfSense and then route the connection directly back onto the Internet.

IPPBX>firewall>Starlink>pfSense>back to internet

@michmoor Gateway Monitor and Monitor traffic graph of each gateway.

@Jenish
Your network diagram shows 192.168.16.0/24 behind 10.1.2.2 and 10.10.10.0/24 behind 10.0.0.2, but your routes point to the respective other gateway.
So what is wrong?

I think it's possible. At least in the part that the VPN tunnel would be installed through a specific provider. It is necessary to register in static routes through which gateway the IP of the VPN provider is available.
It's a pity you can't register a group of gateways in static routes, then your problem would be solved completely

Found the culprit!
Thank you @SteveITS

Screenshot from 2023-11-25 11-57-06.png

No buffering with this turned off!

Dear both

Thank you very much for your answers. This is exactly what I need. Now it works:

21b9352e-3133-4aa6-bca5-41403ba4641f-Unbenannt.PNG

Have a nice day and best regards

And https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/opt-wan.html
Which links to
https://docs.netgate.com/pfsense/en/latest/solutions/netgate-2100/switch-overview.html

@gwaitsi so after re-reading the gateway groups section, i see the default gateway as a load balance pair is an invalid option. i had to select a failover pair.
but i would still like to refresh once a day, so if a failover has occured, the default switches back to WAN1 as the default

oh man... i guess it was a reboot that i missed after changing ipv4_forward in sysctl.conf to 1 - or just do a sysctl -p... however it works now 🤦

@viragomann I was told to just put my DECO in AP (bridge) mode since the PfSense will be doing all the routing and firewall work. Assign IPs from PfSense (and reservations / port forwarding / etc.) from there and be done. I'd prefer to not have double NAT.

@Royplaisier
By the way, I'm a colleague of Simon-cornet

Now that I see your post, I've had the same issue last weekend. The IPv4 Address + Gateway came in via DHCP but I did not check the routes. IPv4 traffic was not possible though for any client. Reverted back to 23.05.1-RELEASE