Default Deny Rules
-
@wifi-will I would have to spend some time looking over that - but what I can tell you right from the hip is multiconnections like that can be problematic when it comes to asymmetrical traffic.
But from a quick glance - I don't see why you would create gateways on pfsense and policy route. That makes no sense - and quick breeze over - it states 2 isolated networks.
-
@johnpoz seem other vendors have no issue just creating static routes between the network. Unfortunately pfsense doesn't allow it because the route is already know. But we still need a rule from TV to Guest via the server as the gateway.
-
@wifi-will A static route is necessary when you're routing to a network behind another router that pfSense has no way of knowing it exists. In your picture a static route isn't needed because pfSense controls both networks.
Keep in mind blocked packets in the log might be benign:
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html -
@SteveITS without the route, all TV's advertise on the guest network and the casting server is not in the middle. With the route, everything works except the reply back to guest.
Seems like i have three options. Test the "bypass firewall rules for traffic on the same interface"
If no. Try sloppy staye on guest and TV rules?
If no. Disable reply to?
This has gone right to the top of phillips and the integrators and its been deemed the negate is at fault
-
@wifi-will If I follow the above, they are asking for the route to be created with a "source" network so it only applies to some traffic, but pfSense doesn't have that.
https://docs.netgate.com/pfsense/en/latest/routing/static.html#static-route-configuration -
@SteveITS so pfsense can't facilitate this configuration? To be it seems quite simple logically but not with pfsense
-
@wifi-will said in Default Deny Rules:
it seems quite simple logically
Logically?? Not really - why would you ever do such a thing.. I can tell you in 30+ years in the biz I have never once even had to think about doing such a thing.
Such a setup makes no sense logically at all. And for sure would asking for asymmetrical traffic flow. It makes no sense logically to route traffic back out into network X to get to Y when Y is directly connected to the thing that would be sending traffic back into X.
If you actually wanted to do such a thing, you would host route it - ie you would put the routes on the hosts in X and tell them go here vs upstream to get to Y.
A locally connected network would always have a better metric in the route table than some other route.
Why would device in X trying to cast to something in Y not just be able to put in the IP of what they want to cast too in Y, and not have to deal with any sort of "discovery" of where to send traffic in the first place.. Now that would be logical.. And make the casting "server" completely unnecessary. Why does the router have to route traffic back in anyway? The router isn't allowing for mdns discovery.. But their "casting" server would be - so in the discovery of looking for something to cast too.. The casting server should hand back its X IP vs the devices IP in Y. So now when user in X wants to cast to something in Y, it would be sending the traffic to that casting servers IP in the X network, vs having to bounce back off the edge router to the casting server just to send traffic to Y.
Client in X says hey looking for something to cast too via some discovery protocol (mdns). Their casting server should say hey I got this stuff you can cast too - send it to me via my IP in X and I will get it to the thing..
What if device in X just wants to talk to something in Y that is not casting? It now has to route this normal traffic through the casting server.. Because its normal router would be routing any traffic destined for Y to the casting server in X. But all of this traffic just going to bouncing back and forth off the edge router for zero reason.
If you tell your edge router - hey don't send out traffic your directly connected interface to get to Y.. Now when something in Y wants to talk to something else say out on the internet.. Your router sends the traffic out to the internet, but its return traffic the router says oh for me to talk to this Y IP vs sending traffic out my directly connected interface to Y, my routing table says to send it to this device in X?
-
@johnpoz its a simple static route that pfsense is incapable of. Having the route known by the routing table already doesn't help me at all because the guest client device has no idea of the caster server is. Without the rule in place, the guest device picks up all TV's on the network. With the static route in place from guest specifically to the casting server, the guest scans the qr code and only sees the room they are in. The casting server is blocking all mnds discovery for the guest devices and only letting through once the qr code has been scanned. I didn't design this system mate. But I'm just trying to make it work. At the end of the day, pfsense being a state based firewall seems its not capable of doing this and I'm only left with using Ruckus routing code and creating the very basic routes there.
-
@wifi-will said in Default Deny Rules:
its a simple static route that pfsense is incapable of
If you really think this, you should obviously ask elsewhere for your problem.
-
@Bob.Dig once again you guys are not being helpful. Thanks for nothing
