Trouble with VLAN
-
@laplacian your camera is likely to want access to a DNS to know were to find your NVR or where on the internet other resources it would like to access are.
When a device on a Lan acquires a local IP address it is normally also told where the local DNS is, which by default is pfsense. For that device to actually access the pfsense DNS, you need to add a local LAN firewall rule to allow that.
-
@patch Like this?
That still didn't seem to do it. -
@laplacian Your camera is not triggering your DNS rule for some reason.
Note your states count are zero which should not be the case if the rule is being triggered.
-
@laplacian You have to put the DNS port in the destination port.
Also don't use WAN_net, it is only a small subnet which is on your WAN port, take a look at Status/Interfaces how small it is.
-
@laplacian said in Trouble with VLAN:
@jarhead said in Trouble with VLAN:
Don't think of outbound traffic. All traffic is evaluated on the inbound side except for floating rules.
Sorry, I'm still having trouble here, and I'm trying some experiments that aren't exactly working.
Let's say I create VLAN 1. By default no rules are created.
So this means that all traffic on VLAN 1 is denied inbound and outbound. (True/False)
I think you're still not getting the inbound/outbound thing. Inbound traffic is generated from the connected network TO the interface of the firewall.
Outbound traffic is generated from something else on the firewall TO the network connected to THAT interface. It has nothing to do with any other interface of the firewall.
So traffic generated from the LAN, outbound would not be to the WAN like conventional thinking would suggest.Now I want to allow traffic from a specific external alias (say, from another VLAN or LAN) into VLAN 1. So I create a rule on the VLAN 1 interface that allows the alias to talk to VLAN 1. (True/False)
False. You have to create the rule on the 'other' interface to allow it's connected network access to Vlan 1. The front door again, the other vlan will either be allowed to access vlan1, or denied at IT's front door.
The alias WAN net is just the network your ISP assigns to your connection from them. It is not the internet. It could be just a /30 but more likely a /21 or so. You are only blocking THAT subnet with that alias. in fact, all the 'net' aliases are just that subnet it references.
Here is my Cam rules:
The VMS I use has a 'Master Server", then multiple Recording Servers.
I have no idea why your NVR would need DNS if it doesn't have internet access but whatever.
My first rule allows NTP to the Master Server, then all edge devices sync to it, has to be that way with my VMS but you can allow NTP to the whole "XXX net" alias and sync all devices to the interface itself.
2nd rule allows my cam net to an offsite network over a vpn.
3rd allows access to an iSCSI storage device.
That's all that needed. Everything else is blocked by the default block rule.
I added 2 additional rules for doing updates, they're disabled until needed.So your "internet" rule is completely unneeded since you don't have an Allow Any rule (and as said above about WAN net anyway), it's already blocked by the default block rule.
I do have to question why your NVR is not on the cam net itself?
Then just allow access from LAN to NVR on the LAN interface. Get rid of the DNS rule, no need whatsoever.
But other than that, your las pic of rules should work but you say it doesn't, What exactly doesn't work?
Are the cameras recording?
Can you access the NVR?
Be more specific. -
Yeah I don't think your getting it..
Your inside your house (pfsense).. And I come to the front door (lan) Do you ask me where I am going, what I want to do before you let me in?
I say hey I want to go to your backyard (optX).. Do you let me in and then stop me as I try end exit out your back door. Or do you stop from even entering the house?
Why would you let me in the front door, to stomp mud all over your clean floors - just to stop me from exiting your backdoor to get to the backyard?
-
Alright, finally had a chance to troubleshoot. It was a switch config error on my part. I had the switch port as untagged, but forgot to set the PVID to the proper ID (was still on default). Once I did that, everything worked perfectly (so far). No DNS rules, etc. needed. Thanks to everyone who helped explain firewall rules--most helpful ( @Jarhead , @Patch , @CreationGuy , @Bob-Dig, @johnpoz).
Here are what my rules look like now:
By what you guys have told me, I'm assuming the second rule is unnecessary. Can you please confirm? If so, is it best practice to leave a rule like this in place or should I remove it for simplicity (which is a best practice :) )?
And finally, let's say I wanted to add a rule that allowed access to the internet. I understand that my WAN is just what my ISP assigns me. What destination would I use to denote "internet"? Would it just be !(RFC1918)? That seems a little hokey. What would that rule look like?
-
@laplacian said in Trouble with VLAN:
What would that rule look like?
-
Leave the block other local access rule in place then add an
-
Allow everything rule but place that rule at the end of the rule list so it is only reached if all above conditions do not apply
-
-
@patch Or couldn't I do it with just one rule?
Allow any source: VLAN50/any , dest: !RFC1918/anyOr is that different somehow? Also, is there a better way to specify the internet other than !RFC1918?
-
@laplacian said in Trouble with VLAN:
Also, is there a better way to specify the internet other than !RFC1918?
Yeah Any.. While ! (bang) rules can and do work, I would stay away from them.. You should be explicit in your rules. Less likely for errors and way easier to read at a glance.
If you don't want stuff to go to rfc1918, then be explicit with that either block or locally reject is sometimes better, because it will tell the client hey your not getting there. No reason to bang your head sending retrans, and waiting for them to time out.
There have been issues in the past when vips are used that can mess up ! rules, if your going to use a ! rule then make sure you fully and comprehensively test that it is in fact working exactly how you want.
You understand 1 rule vs 2 is not going to provide any less overhead or performance.. And is more likely to be written wrong or not work as intended, etc.
