[solved] problems with understanding "advanced" egress filtering
-
@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.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@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.
-
B Bob.Dig referenced this topic on
-
@Bob-Dig said in [solved] problems with understanding "advanced" egress filtering:
Also I got the impression that reply-to on an outbound WAN rule is not a good thing anyways
I am not an expert on reply-to by any means I have not spent any time figuring out exactly how it works. I know is meant to enforce symmetrical flow.
So normally yes it is a good thing. In your scenario if you natted it shouldn't be a problem having it do reply-to.. Without nat you could need to disable it because the flow is asymmetrical
In my scenario the flow is asymmetrical in the sense the macs are different.. But I believe that has to do my vip being different than my wan IP. and with how the cable modems and macs work for normal gateway, etc.
So for example - if I sniff on talking to that 192.168.100.1 address from my 100.2 address... You notice it gets sent to mac A, but the return traffic is from mac B..
See how the mac I send to for syn, is different than the mac the syn,ack comes from. Normally this would be bad and would be seen when you have asymmetrical flow..
Disable of reply-to allows for this to happen from my understanding of reply-to. Why it happens when talk that 192.168.100.1 on my modem not quite sure..
I really should spend some time figuring out exactly how that reply-to works..
So in your scenario without nat - your flow would be for sure asymmetrical, and if reply-to enforces symmetrical that would make sense why it would allow your connection to work.
But if you were natting, I would think you would arp for the wan net IP, have the mac and send the traffic to that mac, and get an answer from that mac..
But I know that my modem when you arp for that 192.168.100.1 I get back answer from the mac I sent too
[23.05.1-RELEASE][admin@sg4860.local.lan]/root: arping 192.168.100.1 ARPING 192.168.100.1 60 bytes from 1c:93:7c:a4:a0:c8 (192.168.100.1): index=0 time=618.497 usec 60 bytes from 1c:93:7c:a4:a0:c8 (192.168.100.1): index=1 time=303.363 usec
But when I ping it.. the answer comes from a same mac.. But when I talk to the modems web gui interface the return traffic is from a different mac..
Which since the mac is different than what I sent traffic too - any sort of something that tried to enforce symmetrical would see that is asymmetrical
My guess is your fritzbox is doing the same sort of thing and answering from a different mac.. Which is why I suggested we do a sniff to see exactly what was going on. Talking to other devices on your wan net shouldn't be a problem I wouldn't think when you were natting.
If you do have other hosts on your want net you want to talk to.. Sniffing would give insight to exactly what is going on.. And you could prob not need that disable reply-to, but only when you talk to something when the return mac is different than what the mac you sent too.
-
@johnpoz I remember that @stephenw10 gave me once the advice to remove reply-to from my VPN-kill-switch, which is a block, outgoing on WAN too.
So my unqualified guess is, it shouldn't be there in the first place.
Too bad I am a network noob not really able to sniff and evaluate that stuff but I see the potential fun of doing it and solving all the mystery.
-
@Bob-Dig said in [solved] problems with understanding "advanced" egress filtering:
not really able to sniff
anyone that has pfsense can sniff - its simple gui packet capture under diagnostics.. Simple packet capture with your frtitzbox IP as filter on host IP.. Then go to your fritzbox gui and post the pcap - and we can see if the mac you send to is the same that answer comes from.
-
@johnpoz Like this? I do nat.
-
@Bob-Dig yeah so what is the macs involved - you see in the syn and then in the syn,ack answer
They look the same - so reply-to disable shouldn't be needed. Is that your fritzbox IP, or some other IP on yoru wan net?
-
@johnpoz said in [solved] problems with understanding "advanced" egress filtering:
They look the same - so reply-to disable shouldn't be needed. Is that your fritzbox IP, or some other IP on yoru wan net?
But it was needed. That is fritzbox (.1) and pfsense (.2).
-
@Bob-Dig hmmm - then I don't understand exactly what that reply-to disable is doing then. From that converstation, it looks to be symmetrical from the macs
