Am I the only one who is missing source-routing?
-
In what kind of a scenario would you use this assymetric routing ?
Most of the protocols don't work when sending packets out a different interface,then the one it was received on.
-
I created a picture for you.
Edit:
The DMZ zones should be isolated (most of them), so that they can only be accessible via internet but not from trusted. Where I really miss PBR is the trusted-to-internet use case, where I have to set the internal-fw as gateway for the answer packets that come from internet-to trusted. At the moment I work around this with some NATs at the internal-fw. That works like expected but PBR is just a better way for this (IMO).
Don't get me wrong maybe my point of view is just outdated and not best pratice anymore, but PBR saved my ass a lot of times and I just don't want to miss it :)Regards
pfs-pdf
-
Why would your external pfsense not be able to route traffic back? As long as it as a route to trusted, it would know how to get there.. Why should there be any need for "source" routing in this sort of setup?
Your internal barracuda shouldn't even be natting..It should have no need to nat.. Your external pfsense should nat the rfc1918 behind it to pubic (internet) Be it directly connected to pfsense or some downstream rfc1918 network.
I can see for sure an asymmetrical problem if your trusted network is talking to dmz without nat.. Since the device in dmz would send its return traffic to trusted to the external pfsense. For your trusted to get to dmz they should go to the external pfsense via the transit to get to the dmz. This way you would maintain states.
-
Why would your external pfsense not be able to route traffic back? As long as it as a route to trusted, it would know how to get there.. Why should there be any need for "source" routing in this sort of setup?
This route isn't set because thats exactly what I try to admit, as I stated above. Source routing / PBR gives me the possibility to route something only for some subnets, not for the whole DMZ. So for the case that somebody opens a firewall by accident, there is still no way to access trusted because it's only routed for some specific connections / sources.
Your internal barracuda shouldn't even be natting..It should have no need to nat.. Your external pfsense should nat the rfc1918 behind it to pubic (internet) Be it directly connected to pfsense or some downstream rfc1918 network.
Yeah but except PBR and static routes there are no more options :) That was just the quick workaround, till we find a solution to setup PBR.
I can see for sure an asymmetrical problem if your trusted network is talking to dmz without nat.. Since the device in dmz would send its return traffic to trusted to the external pfsense. For your trusted to get to dmz they should go to the external pfsense via the transit to get to the dmz. This way you would maintain states.
Thats the future plan. At the moment we are still setup the new outer firewall. I tried not to screw everything at the same time, so I thought its a better idea to do a firewall migration first and then a network redesign.
Regards,
pfs-pdf
-
" So for the case that somebody opens a firewall by accident,"
If that happens you have bigger fish to fry..
But if you do not route back then those devices can not access the internet without natting. But you could just create routes for the specific hosts vs a summary route.. But why would trusted not have access to the internet?
BTW since your having to nat from your rfc1918 to the public - its a pretty big firewall mistake to create a forward.
-
" So for the case that somebody opens a firewall by accident,"
If that happens you have bigger fish to fry..
For me this was just another layer of security - just 3 clicks away :)
But if you do not route back then those devices can not access the internet without natting. But you could just create routes for the specific hosts vs a summary route.. But why would trusted not have access to the internet?
The firewall setup in our company was made maybe 10-20 years ago. I think they just made it like this, because it was best practice at this time. Even it's complicated I like the idea that the internet isn't routed directly to trusted. Clients can only access internet via a proxy and except that, we have really less direct connections that use the workaround NAT at the moment.
BTW since your having to nat from your rfc1918 to the public - its a pretty big firewall mistake to create a forward.
Um sorry - I don't get that. Why should this be a mistake? Isn't NAT used for this?
Regards,
pfs-pdf
-
You would have to forward ports to specific IP.. Its not a 3 click mistake is my point! Its not like oh was suppose to open port X and 1.2.3.4 and opened X to any..
-
Its not like oh was suppose to open port X and 1.2.3.4 and opened X to any..
It's a layer of security, like having two instead of only one firewall. Maybe it's overkill for you but for me PBR is a standard way to accomplish a more granular routing, isolate subnets and do some more crazy things. Pfsense seems to recognize that use already, so they implement the feature at the firewall level. Thats what I want to question, because for me it works only half way.
Regards,
pfs-pdf
-
pfsense does PBR just fine.. you can create your specific host route to specific IP /32.. You do not need to route to the whole network, what you have is asymmetrical setup.. And no without a route its not going to work..
or create host routes on your DMZ that you want to access via your downstream router when they have default gateway. If you remove asymmetrical routing then you no longer have a problem, that your trying to overcome with amounts to a hack vs doing it correctly.
-
pfsense does PBR just fine.. you can create your specific host route to specific IP /32.. You do not need to route to the whole network, what you have is asymmetrical setup.. And no without a route its not going to work..
or create host routes on your DMZ that you want to access via your downstream router when they have default gateway. If you remove asymmetrical routing then you no longer have a problem, that your trying to overcome with amounts to a hack vs doing it correctly.
I think we just discuss about a question of faith already. PBR is no hack, its designed for this. OK, if you don't use it correctly you create asymetrical routing and screw the route, but if you know what you're doing, it fits perfectly. So PBR works not completly fine IMHO, because I can't set an other gateway on the packets that come back. Thats a hard fact. And because of this it is implemented on routing level and not on a firewall level, so that the changed gateway affecteds all packets, not only outgoing.
