@Rico
Thanx ...

Wonder what in his reply : "Makes sense" ... That didn't

@AertightMicah I would back up everything and start from scratch and then restore 1st interfaces, then firewall rules, then IPsec and etc and at each phase will look if that option of speed and duplex is there.

This isn't the post I was referring to, but this seems to sum it up a lot more nicely than the ones I found on the subject. I was a lot less coherent on the subject when I was doing my initial research.

I will give this a try thank you!

Any update?
I'm agreed pay to this solution..
Thx

@techy2493 said in Routing between a net and a subnet:

Is there any reason you can't define a new 255.255.255.0 subnet specifically for your camera system in a different address space?
Thanks. Of course, let's say I am -obliged- to do this: the configuration software of the cameras assign to the devices only a 255.255.255.0 netmask.
In this way they are visible either from the machines in the A subnet or from the nodes in the B subnet, but not from all of them.
So the problem arises when I try to manage the cameras from a machine 'correctly' configured, i.e. with a 255.255.254.0 (belonging to the C=A+B net): if machine in the A subnet it sees only the A subnet, and dually the same for the B sub(half)net.

Your router should be capable of routing between the them on the same hardware. For example I have a 10.10.10.0/24 and a 10.10.11.0/24 using the same network hardware and I routinely switch my machine between them when I need to utilize the other default gateway and firewall rules in my pfsense. Is there any reason you feel this isn't an option?d

No, any particular reason. But having these constraints to the setup I was asking to myself and to the forum if pfsense could be a solution to it.

I finally had a chance to get to the network and do a packet capture while unplugging the primary WAN link. Capture on primary WAN interface shows the tcp syn packets going out the interface bound for the SMTP server, with obviously no response. I then tried to do a capture on the secondary interface while repeating the test and the webconfigurator froze up. I power cycled the pfsense box, and after it rebooted, I am unable to reproduce the issue and the alerts now work as expected. I got a second capture and show the connection to the SMTP server leaving from the secondary interface as expected when the primary interface is down. So.... not sure where that leaves me; the pfsense default behavior is clearly right, and my configuration also seems to be right, but something non-persistent was causing this traffic to route out the gateway interface that was down...

You need to create the 2 network interfaces.. be it you want to make 1 wan and 1 lan in pfsense. Or 2 lan side interfaces.

Issue you run into with using 1 as wan in pfsense for your 2 networks would be pfsense would be default nat..

Your better off doing 1 of these networks on lan, and then creating another lan side network, opt1 be it physical interface via vnic and vswitch in your VM software or a vlan is up to you.. I would do native if me, less complicated.. vlans on vm software can be a bit tricky

So on this new opt1 network, just create the network IP range you want to use... And then create firewall rule that allows access to your lan.

@skilledinept So, here is what I've done. I decided to do a simple physical test. I took my phone from work which I was testing and it was working fine switching from WAN1 to WAN2 under 2 minutes time frame. It didn't switch back to WAN1 when it was back up but I was fine with it.
I brought my phone to one of the satellite offices where phones had one way audio or no audio at all during failover to WAN2. I plugged both phones mine and the one in the office straight into the cellular modem without any firewall and they both worked fine. Then I connected both ISPs to pfSense and plugged both phones with a switch into pfSense. After unplugging WAN 1 phones took about 2 minutes and were back up on WAN2. Except...my phone worked fine but the one from that office had the usual audio problems (if i call to extension inside of our company no audio at all, if i call outside number I could hear but no one could hear me.) Then I took both phones mine and the one from office with audio issues and brought them back to my office. I performed the same test and got the same result. After reading a bit more about SIP I remoted into the phone which had audio issues and switched SIP from UDP to TCP it began working as intended. However, it takes about 15 minutes for the phone to switch from WAN 1 to WAN 2. It also switches back to WAN 1 when its back up unlike with UDP that remains on WAN 2 until phone or firewall rebooted. Both phones have identical config but one needs SIP over TCP while other is fine with SIP over UDP. I called the company with whom we have service and rent the phones and they don't know what to say.

I would like to shorten the time between WAN1 - WAN2-back to WAN1 but I don't know how or if its possible for IP Phones SIP over TCP. There are some options in the phone but I don't which timers I have to adjust to speed it up or if its possible at all. I might have to look back again at scripts from the other post I made before this one.
SIP Advanced.PNG

You could get fancy with the rules, and use rules that mark the traffic based on criteria, and then use those markings in your rules to allow or block, etc.

You can do that with floating rules, that are not set as quick..

So you could mark or tag traffic based on criteria XYZ, and then in later rule on floating do something else with it like send it out a specific gateway. Or on your interface rules look for specific tag and then do X with it..

So he could in his floating rules, non quick set a tag for traffic to tun1, or tun2 or wan.. Then in the interface or floating (later down the rule set) set a rule that is quick that sends it out a specific gateway, or on the interface have rules that say if tagged tun1 send out tun1, if 2 out tun2 if wan out wan, etc. etc..

That's not even the way to do failover, you would use Gateway Groups for that. ;) In my understanding, your disabled rule would never be executed (even if it's enabled) as it matches exactly the same pattern as the rule that comes before.

When you say "physically disconnect the Fibe cable", do you really mean the fibre cable or actually the cable between the pfSense box and your modem? I could imagine that your global routing configuration is somehow in a way that WAN_DSL_PPPOE kicks in as the default gateway. I maybe wouldn't expect that, but I could imagine, that when you physically remove the network cable (which is not the typical real-world outage scenario) from the pfSense box (so that the network interface changes its whole state to disconnected), that the gateway WAN_FIBRE_PPPOE gets removed from the system in a way that it has the same effect as if it wouldn't exist at all and the then active default gateway (WAN_DSL_PPPOE) is used. Just a theory. ;)

Could you please tell a bit more about your setup how exactly you have configured everything (without too personal information of course ;) )? As you mention xDSL, I assume you are using PPPoE? If this is the case, please consider that the IPs/subnets you configured is only to access the management interface. PPPoE (as the name already says) works on Ethernet level (not IP level) and I'm not sure if this works over the same physical interface (not only in theory but also with real equipment), have never seen that.

@akuma1x That was it!!! Thank you very much for your help and @DaddyGo as well!

LaggConfigLACP.JPG

@shararaus

You’d need to create rules based on the ports the applications use then create a firewall rule to push the traffic out the gateway.

It’s in the pfSense manual.

Simply plug in the "secondary" router into a LAN port of your existing network. Could be directly on the pfsense box, then you'll need to fire up an additional interface. Or, it can even be on your LAN switch.

All you have to do is give the "secondary" router a different subnet than your pfsense LAN network.

@monocleitsolutions

FYI - Just to be clear Policy routing has yet to actually work at all.