[solved] problems with understanding "advanced" egress filtering
-
I want to block outgoing RFC1918 traffic on WAN. But also WAN_net is RFC1918. So I want an exception for WAN_net to not get blocked. For instance, I want to access the admin interface on the first router.
I created the following rules and the only way it works like intended is by making the direction to any on the first rule.
But I can't get my head around it. Why is it working only with any?Maybe @johnpoz can help me?
Side note: I don't NAT traffic with WAN-net as destination. IPv6 isn't used.
-
@Bob-Dig said in problems with understanding "advanced" egress filtering:
I don't NAT traffic with WAN-net as destination
How is that working? How does your wan net devices know how to get to whatever your source network is.
Here being a good netizen I too block rfc1918 outbound, because why should I just send noise to the internet.
I allow outbound going to 192.168.100.1 which is my cable modems IP, so I can view its logs and signal strengths, etc. I do nat that because I have a vip on the wan interface connected to the modem of 192.168.100.2. So I nat traffic going to my modem IP with that vip
-
@johnpoz said in problems with understanding "advanced" egress filtering:
How is that working? How does your wan net devices know how to get to whatever your source network is.
It is a router and it has a static route to all of pfSense networks. But my problem was also there when I did NAT, so it is not related. Any thoughts on the initial question?
-
@Bob-Dig why you have to use any direction? That makes no sense..
other than source traffic into pfsense could be blocked by the rfc1918 rule, but then again there should be state that allowed it if the traffic actually going to your wan net went through pfsense.
But you would be better off natting if you have other stuff on your wan net.. Otherwise your bouncing return traffic off their gateway, your upstream router. And the return traffic ie their syn,ack back would be out of state for that upstream router because it would of never seen the syn coming from stuff behind pfsense.
-
@johnpoz said in problems with understanding "advanced" egress filtering:
But you would be better off natting if you have other stuff on your wan net.. Otherwise your bouncing return traffic off their gateway, your upstream router. And the return traffic ie their syn,ack back would be out of state for that upstream router because it would of never seen the syn coming from stuff behind pfsense.
I don't understand, again, the first router has a static route towards pfSense, so everything works as far as I can tell (no bouncing I am aware of ) . And there is a reason why I don't NAT that, because I am able to restart the PPPoE connection (on that router) from an app on a host behind pfSense. It wouldn't do it when I was NATing, the reason I can't tell.
-
@Bob-Dig What do you not understand about asymmetrical traffic flow?
Did you create a host route on this wan net device, saying hey to go to that lan net.. Talk to pfsense IP on the wan net? If not it would send it to answers to traffic from your downstream network to its gateway.. Your upstream router. And your flow is asymmetrical.
if you upstream router is actually firewall and keeps traffic of states.. The answer from your device, ie its syn/ack would be out of state and be dropped.
No matter if your upstream router allows the traffic or not - it is asymmetrical flow..
-
@johnpoz said in problems with understanding "advanced" egress filtering:
Did you create a host route on this wan net device, saying hey to go to that lan net.. Talk to pfsense IP on the wan net?
Yes, that is what I meant with "it has a static route to all of pfSense networks".
-
@Bob-Dig so on every device sitting on this wan net you created routes? Wouldn't it just be easier to nat?
There is no difference in natting to some rfc1918 address than some public address..
-
@johnpoz said in problems with understanding "advanced" egress filtering:
@Bob-Dig so on every device sitting on this wan net you created routes?
No, again, there is a router connected to pfSense on the WAN-port. And that router has that static route I put there. No need to put that route on all devices of WAN_net, they are all connected to that first router.
I kinda wish we could come back to the initial question though.
What is an actually use case where you could use any as a direction anyway. I mean it is helping here but i don't know why.
-
@Bob-Dig said in problems with understanding "advanced" egress filtering:
And that router has that static route I put there
And again - what part do you not understand about that being asymmetrical.. Do you know understand the term?
Your path for traffic and return traffic is not the same, its not symmetrical. It is asymmetrical and if that upstream router was actually a firewall.. It would block the return traffic (syn,ack) because it never saw the syn coming from the downstream network.. And would drop it.
-
This post is deleted! -
@Bob-Dig do whatever you want. I have explained it to you.. You are bouncing traffic off your upstream router for zero reason. And your just lucky its not actually a stateful firewall or it wouldn't allow the traffic.
And showed you how to allow some rfc1918 egress, and block others..
-
So I disabled the NoNAT exception, still I can not open the webinterface of the first router.
-
@Bob-Dig well from those rules - your rule to allow to the friztzbox has never triggered.
Are you doing policy routing? Which forces traffic out a pppoe gateway or vpn or something? Lets see the lan side rules where your trying to come from to get to this modem.
-
@johnpoz said in problems with understanding "advanced" egress filtering:
@Bob-Dig well from those rules - your rule to allow to the friztzbox has never triggered.
I made that screenshot beforehand.
I have many floating rules though...
-
@johnpoz said in problems with understanding "advanced" egress filtering:
where your trying to come from to get to this modem.
It is not a modem, it is a router (with modem).
-
@Bob-Dig so a gateway ;)
Yeah good catch, about the term of "modem" I normally bring that up to others - for thanks for correcting my misuse.
Ok so you rule is allowing the traffic, then the return traffic should be allowed.. Might be possible that the reply too is causing an issue.. I have seen this on my own setup but never actually dug into the actual reason.
You could try setting do not use reply too on your outbound rule that allows access to your fritzbox
I would sniff on your wan when you try and talk to the fritz.. Are you actually seeing syn,ack back? What sort of reply do you see - or nothing?
I am pretty sure the reply to for me is because I am using a vip.. But if your using your actual wan IP in the nat to talk to your fritz then it shouldn't be a problem.. A sniff would be very helpful in figuring out exactly what is going on.
-
@johnpoz said in problems with understanding "advanced" egress filtering:
You could try setting do not use reply too on your outbound rule that allows access to your fritzbox
Holy smoke, that did it! Thank you @johnpoz .
And it is doing it with and without NAT.
Looks like I did ask the right person.
-
@Bob-Dig said in [solved] problems with understanding "advanced" egress filtering:
Looks like I did ask the right person.
hahahahaa
In your setup - nat would be the better setup.. If you had a transit to your upstream router then sure don't nat. But asymmetrical traffic flow is never really a good thing to introduce into your network.
If I was going to setup multiple routers in my network, you should use a transit network. But with that fritzbox I doubt it allows you to create another interface to use as transit?
If you have to use a network with hosts on it as your transit network, and there will be need for communication with the devices on this transit network from networks behind the downstream router. Then either host route (routes on the devices in the transit) Or just nat the downstream networks.
-
@johnpoz Thanks and good to know. Fritzbox has a guest network but I doubt I could use it here. Why I am not NATing everything I noticed here afterwards. But it is beyond my pay grade (knowledge) why this is.
But definitely didn't know that I already have asymmetric routing going. Now thinking about it, I could further narrow this NoNAT rule down...
Also I got the impression that reply-to on an outbound WAN rule is not a good thing anyways, maybe it should be disabled by default? Or we get a troubleshooting topic about it, I would never found the solution on my own, that is for sure.
-