Question Regarding Default Deny Rules
-
It would be at the end of the LAN rules list so that only traffic not already passed would ever hit it.
New connections from the Roku alias would be matched and passed by the existing rules above it.
When the Roku tries to send a TCP:FA flagged packet and pfSense has already closed the state it doesn't match any of the pass rules but will match the custom block rule. Hence it will be blocked as it is now but without logging.
And, yes, I agree with @johnpoz passing the flagged traffic is not the solution here. I blame the cold/flu meds!
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k not talking about your vpn with source IPs - I am talking specific about the any any that allows traffic and sends it out your wan_dhcp gateway.. That is more than likely going to just prevent you from talking to other networks you have local.
And a any for the source other than being lan subnets would only make sense if this interface was being used as a transit network - why would devices be sending traffic to pfsense lan IP, if they were not on your lan subnet.. And lets say they did - they wouldn't be natted, unless you specific setup a outbound nat rule.
Policy routing can be useful - but in your setup doesn't make a lot of sense to have a any any with * for source and then another allow rule with lan as subnet as source.
Again rules are evaluated top down, first 1 to trigger wins and no other rules are evaluated.. Please give a scenario of traffic where your traffic would not match the any any rule on ipv4 that you send out your gateway.. But then match your 2nd rule that is also any any but only from your lan network?
I get what you are saying. Honestly, the any/any rule is the default rule and I left it there. When I started configuring pfsense, I left it there and when I was trying to get the VPN to work as I described, I had to add the rule with the WAN gateway specified because I have an outbound NAT rule for the VPN GW. I did not intentionally leave the default allow any/any rule there fir any specific purpose other than I didn't want to disable the default rule. I suppose I could test disabling/removing one of those rules.
-
@stephenw10 said in Question Regarding Default Deny Rules:
It would be at the end of the LAN rules list so that only traffic not already passed would ever hit it.
New connections from the Roku alias would be matched and passed by the existing rules above it.
When the Roku tries to send a TCP:FA flagged packet and pfSense has already closed the state it doesn't match any of the pass rules but will match the custom block rule. Hence it will be blocked as it is now but without logging.
And, yes, I agree with @johnpoz passing the flagged traffic is not the solution here. I blame the cold/flu meds!
Ok, so if I understand you correctly, you are saying a rule that blocks the roku devices outbound on port 443 placed at the very bottom would not block the "needed" roku traffic and it would only block the TCP:FA flagged traffic, which you are saying is unneeded anyway?
-
Yes, exactly!
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k not talking about your vpn with source IPs - I am talking specific about the any any that allows traffic and sends it out your wan_dhcp gateway.. That is more than likely going to just prevent you from talking to other networks you have local.
And a any for the source other than being lan subnets would only make sense if this interface was being used as a transit network - why would devices be sending traffic to pfsense lan IP, if they were not on your lan subnet.. And lets say they did - they wouldn't be natted, unless you specific setup a outbound nat rule.
Policy routing can be useful - but in your setup doesn't make a lot of sense to have a any any with * for source and then another allow rule with lan as subnet as source.
Again rules are evaluated top down, first 1 to trigger wins and no other rules are evaluated.. Please give a scenario of traffic where your traffic would not match the any any rule on ipv4 that you send out your gateway.. But then match your 2nd rule that is also any any but only from your lan network?
That might make sense if they were opposite where the lan source was above the * source if you were wanting to allow stuff to your other local networks, ie not send it out your wan. But have the * as source makes no sense unless it was a transit network - and putting devices ie the other stuff on lan just leads to possible asymmetrical traffic flow..
Just for reference, here are my outbound NAT rules. Again, these rules and the LAN FW rules in the other pic are what I created specifically for the VPN. Maybe I did it incorrectly or could do it better but that's how I was able to get it to work. There were some docs online that talked about doing the inverse of what I wanted so I tried to implement the inverse of their solution.
-
@djtech2k you don't need * as source in your rule to send traffic out your policy route.. And you only need such a policy route if your pulling routes from you vpn connection and it becomes the default route in pfsense.. Which yes many vpn guides say to do that and change your outbound nat to manual - it is bad practice to do that.
If you only want to send specific traffic out some vpn connection.. Do not pull routes from your vpn service, and create a hybrid nat for it and then policy route your traffic out the vpn connection.
Here is example.
Here I set the client that talks to the vpn service not to pull routes. Then create a hybrid outbound nat to nat traffic to that vpn interface.
Then create a policy rule to send traffic out the gateway I want for only the devices I want, you could use an alias here like you setup if you want multiple devices to use the vpn to get to the internet
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k you don't need * as source in your rule to send traffic out your policy route.. And you only need such a policy route if your pulling routes from you vpn connection and it becomes the default route in pfsense.. Which yes many vpn guides say to do that and change your outbound nat to manual - it is bad practice to do that.
If you only want to send specific traffic out some vpn connection.. Do not pull routes from your vpn service, and create a hybrid nat for it and then policy route your traffic out the vpn connection.
Here is example.
Here I set the client that talks to the vpn service not to pull routes. Then create a hybrid outbound nat to nat traffic to that vpn interface.
Then create a policy rule to send traffic out the gateway I want for only the devices I want, you could use an alias here like you setup if you want multiple devices to use the vpn to get to the internet
Ok so basically you are saying the NAT rule can be more specific and then the extra FW rule wouldn't be necessary?
For the NAT rule, could the source be my Alias or should it be the whole LAN subnet I am using (192.168.x)? I also assume the FW rule would have source as my Alias and set the GW as the VPN GW.
-
@djtech2k said in Question Regarding Default Deny Rules:
AT rule can be more specific and then the extra FW rule wouldn't be necessary?
If you do not pull routes, you would need a rule to send traffic out your vpn. You need that rule sending traffic out your wandhcp because by default pfsense would route all traffic out the vpn.
But your rule that sends out the wanddhcp shouldn't have * as source.. And once you created that rule sending all traffic that doesn't match your vpn rule, the rule below that is not needed and would never come into play.
Yes your setup could be less complex that is for sure.
Messing with auto outbound nats is more work, and could cause you pain if you add another local network and can't figure out why its not working because you set your outbound nat to manual..
-
EDIT: I found the "dont pull routes" in the VPN client config and I just set those options.
Ok where is the setting you mentioned for the "Don't pull routes"? I set my NAT rule so the source is my Alias (eg clients I want going thru VPN) but it stopped working.
So for the FW rules, I have a rule sending traffic for the VPN to the VPN GW and the other rule that sends "everything else" out the WAN GW. Are you saying I will continue to need both? When I tested this whole thing with the VPN, I could only get it wo work with both but I want to confirm if I am making changes to make it better/more simple, then I want to make sure its working as expected.
-
@djtech2k no you would not need the send traffic out your wandhcp gateway if your vpn is not the default route. All you should need is the default any any rule below your vpn routing rule that has lan subnets as source
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k no you would not need the send traffic out your wandhcp gateway if your vpn is not the default route. All you should need is the default any any rule below your vpn routing rule that has lan subnets as source
Because I am pretty new to pfsense in this use case, where is the default route specified or determined? I do not have any static routes configured and the gateways are set to automatic in pfsense.
-
@djtech2k look at your route table, either under the diagnostic menu or via cli
When you let the vpn connect pull routes - it will override your default route - which would be just pointing to your gateway you got from dhcp from the device in front of pfsense be that some other router or your isp.
-
@johnpoz said in Question Regarding Default Deny Rules:
@djtech2k look at your route table, either under the diagnostic menu or via cli
When you let the vpn connect pull routes - it will override your default route - which would be just pointing to your gateway you got from dhcp from the device in front of pfsense be that some other router or your isp.
Ok, so I checked the "Don't pull routes" checkboxes as suggested above. So should that be checked and my FW rule should not have to specify the DHCP WAN Gateway, or am I getting that wrong? I of course can go test the settings and see but want to understand what you're saying.
-
@djtech2k if you do not pull routes, then your default gateway should be that wan_dhcp gateway anyway. You would only need a rule to force traffic out the vpn tunnel for the devices you want to use the vpn.
-
As of right now, I have the following config:
VPN: Do Not Pull routes boxes (2) are CHECKED
NAT: Hybrid with rule on OpenVPN Interface, Source = My Alias, NAT Address = VPN Client Address
FW: Allow From My Alias, Any Destination, VPN Client GW
FW: Default Allow LAN Subnets to Any/AnyIt seems to be working as expected. When I add an IP to the Alias, it goes thru the VPN and all other traffic just goes to the WAN. I am not familiar with the "Pull Routes" setting. I see it says its whether routes will be added to the client route table or not, but I am not clear on whether that is needed or if it should be disabled. This VPN client config is really just for when I want some specific devices to go thru a specific VPN connection.
Unrelated, I do have OpenVPN Server running on pfsense for the purpose of remote connectivity/management.
-
@djtech2k yeah you can run a server as well - has nothing to do with these rules. Or policy routing.
-
So does the config I described make sense and it the best way to do it? My basic testing seems to look like it works but I am just testing basic connectivity.
-
Sorry to circle back to the earlier conversation but I put in a FW rule at the very bottom that looks like this:
I just checked my FW log and I am seeing Roku packets blocked with a port 443 destination. IDK if its as many as it was, so maybe lower volume, but there are some there. Here is an example:
Any idea why these log lines would show up with that FW rule in there?
-
@djtech2k that rule you have there with 0/0 has never been evaluated.
You sure that 192.168.x.x is in your alias - it pretty pointless to obfuscate rfc1918.. Like trying to hide you live on the planet earth.. Nobody can do anything with your rfc1918 space..
My machine is 192.168.9.100, my nas is 192.168.9.10 my ntp server is at 192.168.3.32 - what would you do with those IPs? You going to hack me now? ;)
I would have to do some testing, but my default deny has been off for year and years.. I setup a rule to log what I want to see.. For example on my wan I only log syn packets, and some common udp ports.. I don't care to see all the other noise out there.
But my from the hip thing to look at since that rule has never been evaluated is that your IP is not in the alias that is being blocked and logged by the default deny.. Look in tables under diagnostics
What I would do is just turn off default logging.. Your any any rule above is going to allow everything.. So anything blocked is going to be out of state anyway.. There is zero reason to see that noise.
-
Try enabling 'any TCP flags' on the block rule in the advanced section.
