@makq it will be fixed when they release next update.

@nickf1227 Wanted to give you an update. I was able to resolve the issue by hard coding the gateway IP monitor address to 8.8.8.8. Starlink is working great on my SG-1100 now.

@qwerty123 My generic understanding of it is: The WAN interface of pfSense is continuously pinging the device it is connected to (e.g. a modem, an ONT, etc...). If you open the advanced drop down you will see a bunch of settings that control this behavior. Essentially if the WAN interface does not get a response from the device it is connected to for a certain period of time it will treat the WAN interface as if "the gateway has gone down". When the WAN interface is down no external traffic can enter or leave the pfSense box. There are some additional settings under Settings > Advanced > Miscellaneous > Gateway Monitoring that are affected by the gateway "going down".
This become particularly important when there are multiple WANs. When WAN#1 fails it may be desired to automatically switch over the WAN#2. This makes it possible for pfSense to know when to stop using WAN#1 and instead use WAN#2.

When Gateway Action is selected the WAN interface(s) do not check if it has a connection. This means the WAN interface is treated as though it is always up. In the example I used above with x2 WANs; if WAN#1 is never marked as down then, WAN#2 is never utilized, and external bound traffic will not be able to enter or leave until WAN#1 is back up again or until manual intervention.

For the majority of users, Gateway Action should stay un-selected. This will allow pfSense to automatically do its thing in the background.

@antionline Yes by adding some extra custom config to Resolver, but I don't remember the exact syntax. I had to do it once for my wife who was playing a mobile game that would slow down if it couldn't talk to its ad servers so I had to figure out a way around it. I no longer need it so I deleted the config months ago.

Edit: Found it in an older backup config.xml. The address to bypass pfB was 192.168.88.110.

server: access-control-view: 192.168.88.110/32 bypass access-control-view: 192.168.88.0/24 dnsbl view: name: "bypass" view-first: yes view: name: "dnsbl" view-first: yes server:include: /var/unbound/pfb_dnsbl.*conf

@djinn1 I fixed the problem after 20 hours messing with settings. The problem was pfsense version 2.51.

They fu**** it up with the latest version. I downgraded to 2.5 and everything works as it should be. I just backup all the setting before and restored same settings.

@viragomann It seems that the problem is only when i download torrents, even if i use a vpn server! need to find a solution

I attempted to submit this as a bug on this issue but it was rejected blaming it on my configuration or my provider. the problem doesn't exist with release candidate 2.5.1.r.20210403.0300. As I stated no config changes were made. The configuration has worked for several years However with version 2.5.1 and later the packet loss issues appear. I roll back to the release candidate or older all works as before. I've installed from scratch & attempted multiple configuration changes with no success. Is there anyone using multiple OpenVpn clients in a similar failover fashion confirm that this problem stated above does or does not exist for them? When community forums aren't helpful and bug reports are rejected where does one turn? OPNSense?

Finally, the problem was that this IP is from an NDS server (it is a DC) that is delivered by DHCP to Pfsense and it creates the route as local, although it is on the other side of the VPN tunnel.
We have configured the DNS of the manual Pfsense and we have not added that server and the problem has been fixed.

@jarlel Traffic is policy routed when it enters an interface.

Traffic sourced from localhost never enters an interface so it cannot be policy routed.

After I connected WAN back it stayed out of the group and marked as down. I released and renewed it's IP, that didn't work. I then just had to go to system, routing, and on the gateways page change nothing, just hit save and then apply. Then it came right back online into the gateway group, routing started working to it, and dynamic dns picked up and also updated the ip. This should have happened automatically and is I guess another issue but maybe related.

Doesn't seem I'm having a lot of success with automatic things with dual WAN's on a LAGG with an XG-7100

As long as nothing else uses that port, you can tie destion IP or Range/Netblock with that port.

Kind of problematic if they use say 443 or 80 or any other port that some other site/service will use. So you need to use enough variables to only route that specific traffic and not traffic you don't want to go out that gateway.

Why source IP is used - is it simple that if that changes its completely under your control. Problem with destination IP is most stuff is served via some sort of CDN these days, and IPs used could be in the 1000's or 10's of thousands - and they can change all the time.

Same with port, they are not always unique to whatever site/service you would want to route out a specific gateway.

While you know your source IP is what you set it to be, and won't be changing unless you change it.

But any combination you can come up with that makes the traffic unique enough to identify can be used.

Please delete this my issue is solved.

@evgeniysk said in server from LAN can't access themself via Virtual IP on WAN interface:

Ok, is it possible to change this behavior?

Yes, with NAT reflection. That means that a NAT rule on an specific interface (mostly WAN) is also implicitly applied on other interfaces. Not preferred, but there is no other option, it's a way to go.

You can activate it either in the respective NAT rule (at the bottom) or globally in System > Advanced > Firewall & NAT.
You can try the pure NAT mode, but if the server needs to access himself you possibly need the proxy mode.

@evgeniysk said in server from LAN can't access themself via Virtual IP on WAN interface:

Server pings itself by public IP, that configured on pfSense, so traffic must flow through it some way.

Without a NAT rule for ICMP + reflection, there is no possibility for the server to ping himself by using the public IP. You may be able ping the public IP though from the server, but this is owned by pfSense, so the firewall might response to such pings.
You may sniff the traffic on the internal pfSense interfaces to verify. If the server himself respond to the ping, you would see the packet twice, one time from server to pfSense and a second time back to the server.

Hi, I solved it like this :

create /usr/local/bin/reset_voip_states.sh

#!/bin/sh

#Kill Udp Sip States after new wan IP
echo "Killing States from ASTERISK pbx to SIPPROVIDER" |logger;

#kill freepbx connection
/sbin/pfctl -k ASTERISKIP

/sbin/pfctl -k ASTERISKIP -k SIPPROVIDER
/sbin/pfctl -k WAN1IP -k SIPPROVIDER
/sbin/pfctl -k WAN2IP -k SIPPROVIDER

chmod 755 /usr/local/bin/reset_voip_states.sh

Edit config file /conf/config.xml

<system>
...
<afterfilterchangeshellcmd>/usr/local/bin/reset_states.sh</afterfilterchangeshellcmd>
</system>

works like a charm
greetings