[solved] problems with understanding "advanced" egress filtering

Bob.Dig · Jul 24, 2023, 11:20 AM

@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.

johnpoz · Jul 24, 2023, 12:35 PM

@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.

Bob.Dig · Jul 24, 2023, 1:09 PM

@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.

johnpoz · Jul 24, 2023, 1:09 PM

@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.

Bob.Dig · Jul 24, 2023, 1:43 PM

@johnpoz Like this? I do nat.

johnpoz · Jul 24, 2023, 1:58 PM

@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?

Bob.Dig · Jul 24, 2023, 2:06 PM

@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).

johnpoz · Jul 24, 2023, 2:08 PM

@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

Bob.Dig · Jul 24, 2023, 2:15 PM

@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...

johnpoz · Jul 24, 2023, 2:40 PM

@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..

Bob.Dig · Aug 17, 2023, 6:53 PM

@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.

johnpoz · Aug 17, 2023, 6:57 PM

@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.