Well that escalated quickly! You just need a firewall rule to pass the traffic from 192.168.5.0/24 since that is not in the LAN subnet. pfSense only default firewall rule is for the LAN subnet. Anything else you wish to pass requires rules adding. Did that not work when you added it? Steve

@viragomann I think I get what you're saying. I'll play around with it. Thanks.

Additional info. When running Suricata on both WAN and LAN it stops working... Disabling Suricata on the non tagged interface (WAN) makes it run again.

@unsichtbarre said in pfSense as front end for /24: Could I just disable firewall in advanced settings? You could - but now you just exposed pfsense web gui, ssh etc to whatever can talk to any IP on the box.. Disable the firewall might be an option for some internal use of pfsense as just router. But not something I would suggest for when its routing public IP space. As mentioned in another thread - just use any any if you want to just route.. There is no advantage to disable the firewall aspects unless its performance related - and if your box can not route your traffic at speed with firewall enabled then it undersized anyway. Then you can at least filter who can talk to the pfsense gui, etc.

@viragomann said in Secondary WAN and High Availability: @bp81 Exactly. That is what VLANs are meant for, running multiple L2 networks on a single hardware. Yeah, I suppose that does make sense, it just never occurred to me to do it. I'm running an HA configuration now with a competing product using separate physical interfaces, but the router I'm using has 8 interfaces, so it's not as if I needed a vlan for this purpose to economize on limited interfaces either.

@unsichtbarre said in /24 from Cogent: I'm wondering if PFS can be used as a front end router? Yeah sure that is not a problem..

@steveits Packages installed ? NONE. CPU usage: about 50% when not doing the test (and otherwise no activity) No change when the test begins and ends. After the test has ended however, CPU Usage climbs from about 50% to 98% for 5 seconds, then it returns to its normal 50%. At the end of the day, it seems to me the SG-1000 may well be the bandwidth limiting factor. Should this be the case, then I will not change anything as I do no need such a high bandwidth anyway. Thank you for your kind assistance.

I just tried adding a Monitor IP to an existing gateway and had no error. Perhaps related to the VPN?

@boumacor Oh yes, Thanks for your concern.

@johnpoz said in Routing to client with wrong default gateway: @boumacor your welcome - glad you got it sorted. Yeah enough coffee does help ;) Coffee and pizza :)

@burninbogey6 said in Setting up routing: "when the WRT1200 is in bridge mode, it disables most of the router functions " dont use bridgemode, dus try with regular mode, don't use WAN port and connect the lan port to one of the ports of the switch. You might need to setup a gateway (ip adress of the pFsense device) in the LAN interface of the WRT1200 to get everyting working.

@viktor_g Might this will be helpful [2.5.2-RELEASE][admin@canlfw03.networklab.prod]/root: frr-reload /usr/local/lib/frr/frr-reload.py:805: SyntaxWarning: "is not" with a literal. Did you mean "!="? if line is not "exit-vrf": vtysh failed to process new configuration: vtysh (mark file) exited with status 2: b'line 46: % Unknown command: network 10.18.130.0/24 area 0.0.0.0!\n\n' Exiting: failed to connect to any daemons. Traceback (most recent call last): File "/usr/local/lib/frr/frr-reload.py", line 1424, in <module> if not vtysh.is_config_available(): File "/usr/local/lib/frr/frr-reload.py", line 116, in is_config_available output = self('configure') File "/usr/local/lib/frr/frr-reload.py", line 105, in __call__ raise VtyshException('vtysh returned status %d for command "%s"' __main__.VtyshException: vtysh returned status 1 for command "configure"

@viragomann maybe the php-script does something else than the shell command does

@viragomann The odd thing is that both gateways are available. If you ping the gateway - it is available, if there is something behind the gateway - the packets just seem to be dropped. I agree about the route 0.0.0.0/24, yesterday I did not realize it a little. Now I turned it off, it seems, it continues to work. I continue to monitor)