IP Network alias block all but one

johnpoz

@mer ok we should look into this a bit more.. I have the same sort of setup with a cable modem I hit at 192.168.100.1 with a vip setup 192.168.100.2 on pfsense and outbound nat, etc.

And block rfc1918 rule in the floating for out direction out the wan.. Just really trying to be a good netizen keeping noise off the internet..

Now maybe I need more coffee this morning - but creating the floating rule allowing dest to 192.168.100.1 out should be enough.. Since the state should allow it back in..

And even if no state a rule with destination of 192.168.100.1 on the wan would never trigger, etc.

But I was able to duplicate what you found. If the rule is set for out direction only it doesn't work, but if set to any direction then it works.. Have to look to the details of the rule getting written when set out only vs when set to any..

But unless my brain is still foggy this morning - something is off here, you shouldn't need any vs just out..

mer

@johnpoz More coffee is always good, even if brain is not foggy :)
But yes, that is exactly the same findings. The only thing I didn't verify was floating rule having only out and not having the WAN "block 1918 addresses". Since that should only affect connection initiation, not return traffic I didn't think I needed to check that. Of course I could also try adding an explicit pass sourced from 192.168.100.1 on the WAN interface rules above the block rule.

ETA:
pfSense 2.4.4-p3 on sg2440 Yes I know it's ancient, I have a 5100 up to date with same ruleset just waiting for right time to switch in.

I tried added a pass source 192.168.100.1 on the WAN above the "block private networks" rule you get when checking the box and the GUI would not let me move my rule, so can't try that configuration.

pfctl -t rfc1918 -T show
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16

pfctl -sr shows for my two floating rules:
With direction of any:
pass quick on igb0 inet from any to 192.168.100.1 flags S/SA keep state label "USER_RULE: Allow Cable Modem"

block drop out quick on igb0 reply-to (igb0 73.89.156.1) inet from any to <rfc1918> label "USER_RULE: Block RFC1918 from going out WAN"

With direction of out:
pass out quick on igb0 reply-to (igb0 73.89.156.1) inet from any to 192.168.100.1 flags S/SA keep state label "USER_RULE: Allow Cable Modem

johnpoz

@mer said in IP Network alias block all but one:

reply-to (igb0 73.89.156.1)

Well that is odd..

edit: So I toggled the reply to in advanced, and change the rule to only out and its working now.. Something wrong with that auto reply to

now rule looks like this

[21.05.2-RELEASE][admin@sg4860.local.lan]/var/unbound: pfctl -sr | grep test100
pass out log quick on igb1 inet from any to 192.168.100.1 flags S/SA keep state label "USER_RULE: test100"

mer

@johnpoz Yep. That's why I added my version info. I'm assuming you tried it on a newer version.

If I don't put the pass rule in, but manually do:
pfctl -t rfc1918 -T add "!192.168.100.1"

to say "not that address" it works fine. Of course the GUI won't let me say "not this host" when defining a network alias.

ETA:
Ahh I didn't look for the reply-to in the advanced. That corrects the problem, but begs the question "should it have been added by default?". Not sure of the answer to that.

Thanks for poking at it.

johnpoz

@mer something odd with the reply to thing.. I toggled this in the allow 100.1 rule to get rid of it..

Which kind of makes sense since how does that rule know your using a vip.. So another odd thing to be aware of when using vips.

mer

@johnpoz Just verified that corrects it for me also.
Hmm. Now dig back into my pf books and see what reply-to actually does. Perhaps on "out" rules it shouldn't be there.

mer

So refreshing my understanding of reply-to I think that if a floating rule is defined for direction "out" (not any or in), the reply-to should be disabled by default.
If the rule is "in" or any, it should be defined. Which is the exact opposite of the current behavior, so POLA :)

Anyway, I'm satisfied with getting it figured out, hopefully this all helps others.

mer

@johnpoz
Just to make sure I'm understanding acronyms, "vip" virtual IP, aka an alias on the WAN interface? Basically gives you an explict route for the 192.168.100.0/24? I don't have that configured, I'm just letting the default route out the WAN take care of if.
But I see the advantage of configuring pfSense that way.

Thanks.

johnpoz

How are you talking to 192.168.100.1 if you don't have an address on the 192.168.100 network?

While yes it "can" work with cable modems - it really shouldn't ;)

Your wan is say 72.52.47.103 some public IP -- and while on the same L2, it shouldn't be able to talk to 192.168.100.1 without sending that to its gateway. Which sure runs through your cable modem to get to the gateway....

So you create a virtual IP on the wan interface to be on the 192.168.100 network, etc and then nat your lan side network to that 192.168.100.2 address.. Now all is right with the world ;) 2 devices on the same L3 talking to each other over their common L2 network ;)

https://docs.netgate.com/pfsense/en/latest/recipes/modem-access.html

Many cable modems will work with the different L3 networks talking to each other because they are on the same L2 network, but really not "proper" ;) which is why create a vip.. And pfsense has to send traffic out its connected interface to get to this 192.168.100 address that it doesn't know about, etc.

mer

@johnpoz
WAN of pfSense is connected directly to the cable modem, on pfSense the default route is out WAN to ISP gateway somewhere beyond the cable modem. So I'm assuming the packet with the dest addr of 192.168.100.1 is going out default route, and the cable modem swallows it without sending it on.
consoled to pfSense, shell, ping 192.168.100.1, something responds to the ping.
I know when I browse to that IP I am getting my cable modem, so I guess it's just network magic happening.

Anyway, thanks for the help figuring out and I'll look at the VIP stuff.

johnpoz

@mer yeah agreed with many cable modems it can and does work without the vip, but it really from normal network point of view it "shouldn't" ;)

It can and does because the cable modem responds.. And yes pfsense has to send the traffic to the cable modem to get to this 192.168.100.1 IP because that is its default route to get to some IP it doesn't know about.

To make it be more "proper" creating a vip that puts this interface on the same L3 your wanting to talk to makes it fit nicer into how networks are suppose to work ;)

What if for example your cable connection via your cable modem was not the default gateway? Then pfsense wouldn't know where this 192.168.100 network was - and would send the traffic out its default gateway. Ie if you had more than 1 wan connection for example.

mer

@johnpoz Yep, having it properly setup is better in the long run than just having it work by magic.

johnpoz

@mer said in IP Network alias block all but one:

than just having it work by magic.

hehehe - not sure I would call it magic, but yeah I personally like to see it setup so it makes more logical sense..

mer

@johnpoz Just a quick note, I was able to get the VIP stuff set up and working. Took a little bit to get the right pieces, but it worked pretty much as advertised in the doc you linked. Thanks