Well, by design pfsense dpinger and related routing table updates of bsd won't let you use the same ip address. A routing table for specific IP is just that: it allows an exit on a specific interface. If you connect to your vpn provider through different servers , a new gateway is created for each connection . Also, If your provider happen to give you the same IP for 2 or more connections , it might be game over conflict for connectivity tests and maybe gateway status. The solution to your problem is not to monitor the vpn gateway ip which is the same on every server , except the first connection, but choose a well known ip , e.g 1.1.1.1 or 8.8.8.8 as monitor IP for each vpn gateway. If you need to compare vpn connections , it will not be a stable basis for comparisson , as the external ip will have longer ping times by a 25% margin approx. I understand your concern from a paranoid security point of view, as pinging a vpn gateway does not leave any traceable exposure on vpn exits for your pings..where advanced adversaries might interfere with.. The limit of monitoring with a single IP the connection status tries to tackle a new advanced plugin which is under development for the time being..Since then, try, to diferentiate your monitor IPs for each gateway manually..

Took you since june to do that? ;) This is connection is via a transit network I hope, you don't have hosts on the network your using to connect to your downstream?

No. DHCP on LAN is enabled by default and all traffic from LAN clients is passed by default. Hard to say what you might have done wrong with the information available.

@Skye125 said in Multi-WAN rule set not allowing access to IP GUI: ange the gateway group back to "default" it all works correctly. Is there something I am You need to create the firewall rule to access the devices, leave the default gateway in the rule as default. Like this: LAN TO MGMT_NET -> PORT 80 443 22 (choose the ports here that you manage the devices).

Here are the routes and rules: PfSense Rules: Interface: WAN Protocol: IPv4 UDP Source: all port: everything destination: WAN address Port: 1194 routes on OpenVPN 192.168.1.0/24 via 10.8.0.1 routes on Mgmt Computer: 172.16.1.0/24 via 192.168.1.200 The route on OpenVPN has been added by the config file of OpenVPN (route 192.168.1.0 255.255.255.0) to reach the remote network through the VPN. Concerning the routes on pfSense, there isn't any static routes, only the gateway to get out to Internet by the WAN interface. Are there any parameters missing? because according to a tutorial that I followed, I only opened the port allowing the VPN connection to pfSense on the WAN interface

I'm by no means an expert at any of this, just on a quest to solve my own similar situation. The Reset States states GUI command always worked for me, though its a bit like using a sledgehammer for a thumbtack. Wonder if the device(s) on your network are so quickly reestablishing the connection that it just appears to to not kill the state? Your Web GUI on the VoIP may have a setting to allow you to adjust the re-registration time of the phone. If you can access it, perhaps increase the time. The scripts I've used are run automatically by cron (install the crontab package to easily manage cron jobs). Still, not an ideal solution. You could also schedule a reboot via cron. You might look into if you can disable then reset the failover wan interface via a command (not sure if you can.) Look at your Firewall Optimization Options under System > Advanced > Firewall & NAT. If its not already, try Normal or Aggressive. This changes the state timeouts. Scroll to the bottom, and you can fine tune those even further. In Diagnostics > Command Prompt, run "pfctl -st" to see you actual State Timings. Changing the above from say Normal to Aggressive should reduce the time outs. Hope this helps. Here are my state times outs with Agressive: tcp.first 30s tcp.opening 5s tcp.established 18000s tcp.closing 60s tcp.finwait 30s tcp.closed 30s tcp.tsdiff 10s udp.first 60s udp.single 30s udp.multiple 60s icmp.first 20s icmp.error 10s other.first 60s other.single 30s other.multiple 60s frag 30s interval 10s adaptive.start 241200 states adaptive.end 482400 states src.track 0s

@Derelict I would personally put the switch management interfaces on VLAN99 so the switch management interfaces were out-of-band from the user data. Sorry... to clarify these are not our actual network/subnets, I just made a quick simple version to ask the question here. In our case no user-data on VLAN1 (I don't think so anyway!). All user data is in their own respective VLANs. VLAN1 is basically network operation VLAN and VLAN99 is for management PC's and a couple other things like that. VLAN99 can see into everything . All unused/not in use switch ports moved to VLAN666. Anyway I guess since we're not really using the switches for routing (just trunking everything back up to pfsense) then I just needed to add ip default-gateway 192.168.0.1 and seems to work now.

@chpalmer Thank you. In germany the providers don‘t want to offer it. Is it possible to host a cisco mlppp server inside a virtual machine? Some other companies like lancom do provide a virtual router.

Before trying the scripts, you may want to check "firewall optimization" is normal or aggressive. The VoIP configuration docs suggest conservative, which could be aggravating this particular problem. I've bumped mine to aggressive, but have no idea if this will cause other issues. https://docs.netgate.com/pfsense/en/latest/book/config/advanced-firewall-nat.html#config-advanced-firewall-optimization https://docs.netgate.com/pfsense/en/latest/book/config/advanced-firewall-nat.html#state-timeouts

@Gertjan said in Help is needed with understanding of Trigger level documentation: When the WAN cable is ripped out, or the router (or modem) up stream goes down, the NIC will signal a LINK DOWN. No need for pinger to determine if ICMP packets come back, and measure the time. They won't come back, they can't even been send away. That's an event that will take down the gateway in the routing table. pinger, can detect if there is an upstream problem, and uses ICMP packets to detect if the upstream path is available. If it is to bad, the gateway is likewise considered as down. And this is exactly for the case when "Member Down" is selected, right? So it triggers to the "down" state when ping is bad, despite the fact that the link associated to this interface is "up"? Someone actually verified this by an experiment? I cannot do this right now because I have no test environment, just production.