@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

192.168.1.0/24 via 10.8.0.1

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.

@JeGr thanks for your response

Strange. Did you already reboot the pfSense box?

Some guys who had similar issues here succeed after pulling down the OpenVPN server or the whole pfSense and rebuild it again.

@Derelict said in Multiple wan att bypass:

They should not give you 64 addresses on an interface subnet.

They should give you a /29 or /30 on the interface and route the /26 to you there.

That way you could, in turn, simply route the /26 to the cPanel server for use there.

Else you have to bridge or NAT. Neither is a proper solution when compared to a routed subnet.

What I am trying to setup is so cPanel can go out and pull what ips it wonts to use. and I can't figer out how.
I got a subnet of 255.255.255.192 with 61 useable ips. but a block of 64.