Question Regarding Default Deny Rules
-
@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.
-
@stephenw10 yup that would be my next thing to check.. Its possible that block rule is only looking for syn to block and not log.
-
Yes, I would usually use 'any' protocol on a rule like that. Setting it as TCP only means you need to specify flags. I think!
-
@johnpoz said in Question Regarding Default Deny Rules:
@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.
Fair enough. Its just habit to redact stuff, so I don't even really think about it when I do it.
I understand your point about disabling the log and adding entries to target specific stuff to log. I am just in the beginning stage of using pfsense on this network so I want to just monitor it a bit before I disable or mask the logging. I realize it will probably be fruitless but again its the comfort of habit if nothing else. I would also say that learning some of these things is also to help me in the event I have to troubleshoot packets being blocked in the future. Learning about the default deny rule will serve me well for sure.
I did double check and the IP from that log entry is 100% in the Alias.
-
@djtech2k then you might have to do what @stephenw10 mentioned about the states.. Its possible that block rule is only looking for syn to block and not log, and the fa are falling thru all the way to the default deny still. Which would explain the 0/0 showing it has never triggered ever.
Or set it to any vs tcp might do the same thing has he mentions in next post.
-
I changed the FW block rule and checked the All TCP Flags block. I will monitor the logs and see what happens.
-
@djtech2k prob just set to any for the protocol as well vs calling out tcp. it would be a cleaner looking rule.
-
I just saw more logs from roku with the TCP:RA flags so I guess I will try any protocol. This seems so strange to show up as it is setup.
