[solved] problems with understanding "advanced" egress filtering
-
@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
-
@johnpoz It has no purpose on an outbound wan-rule and further does something bad, if it exists. I don't think that it is a coincidence, that we both needed to disable it...
-
@Bob-Dig mine I thought I understood because the macs are different from where I send and where the reply comes from. But in yours the answer is coming from the same mac your sending too..
You sure you need it when talking to that IP.. I could see needing it when talking to some other device on the wan net, that bounces its return off your fritzbox.. Then it would make complete sense when not natting..
edit: Ok its something weird when you use outbound blocking rules.. So when I disable my block rule of rfc1918 and my allow rule for outbound to 192.168.100.1
It works just fine.. But if I add block rfc1918 outbound, with specific allow of 192.168.100.1 before it - then have to disable the reply-to...
Hmmmm?? Something is odd for sure..
-
B Bob.Dig referenced this topic on
-
@johnpoz said in [solved] problems with understanding "advanced" egress filtering:
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
Btw
I bet you don't need that vip to connect to your cable modem. When I had cable internet, I could connect without it. -
@Bob-Dig said in [solved] problems with understanding "advanced" egress filtering:
I bet you don't need that vip to connect to your cable modem. When I had cable internet, I could connect without it.
True my last cable modem I could without the vip.. But I leave it setup so its easy to show people how to do it if need be.. I haven't actually tested with my new S33 I got a while back.
-
J johnpoz referenced this topic on
-
J johnpoz referenced this topic on