Weird VLAN problems
-
Can you give me some hints how one can create tagged VLANs interfaces in pfSense which will play nicely on the same subnet (192.168.1.1/20)?
This doesn't make any sense. The reason to create multiple VLANs is to isolate networks, not combine them.
-
Ok. If VLAN doesn't make any sense in this scenario, how can this requirement be fulfilled otherwise?
I want to ensure that clients connected to the Wifi-device can't communicate without being routed to pfSense…
I would be glad to have some hints. Thanks a lot! -
VLANs make perfect sense. What doesn't make sense is having everything on the same 192.168.1.0/20
VLAN 100 - 192.168.100.0/24
VLAN 101 - 192.168.101.0/24
VLAN 102 - 192.168.102.0/24To your firewall they are separate interfaces and can be treated as such, with rules passing or blocking traffic between them.
-
The only reason why I am currently not going for this solution is that this will break multicast and device discovery and I have absolutely no idea how I can forward such packets from one subnet to another…
Would it be a better idea to add another physical network port (e.g. USB) to my pfSense and connect the Wifi router directly to that port?
I mean I am about routing and filtering network traffic within my network. -
No, having a physical port will not change anything (except for making things massively worse if it's USB.)
With the nonsense you are producing with VLANs, just ditch the VLANs and hang everything on the same dumb switch on a single subnet.
-
^ exactly… What multicast are you trying to pass exactly?
And what devices need to use this multicast.. There are plenty of ways to design the network to allow your multicast to work while still isolating other devices, etc. Simple solution is to just put the device that uses multicast and the devices that access this device via multicast on the same layer 2.
What exact devices are you working with?? Its quite possible you don't actually need multicast but just need to proxy some info like mdns which could be done with avahi..
Example.. My ipad and phones using airprint to my printer.. So I could of created some dns stuff to allow them to find the printer.. But it was easier to just put the wired printer on the same layer 2 as the wifi network those devices connect to. My other devices that use the printer don't use airprint and just need the IP of the printer to send prints across the segments, etc.
If we know the devices and exact protocols you are working with or think you need, which might not be the case we can work out how best to segment your network and provide the security boundaries you want.
-
Hi johnpoz,
the devices in question are basically several IoT devices and gateways, such as an Orvibo AllOne (IR+RF 433MHz blaster), Xiaomi Gateway (ZigBee hub), Xiaomi Mi Robot (Robot vacuum) among others. Most of the mobile apps which control these devices use UDP multicasts for discovery each time you start to establish a communication.
While I am using Domoticz on a Raspberry Pi to keep things together (actually you don't want to use plenty of different apps to switch a light etc.), the apps are required for non-daily tasks (like driving the vacuum into another room).
As soon as I put these devices into a different subnet… Well, you know the result. ))
On the other hand, leaving my network the way as it is now is also a no-go.While digging deeper into possible solutions for what I am trying to do, I came across this tutorial (Author derelict?):
https://www.infotechwerx.com/blog/Creating-a-Simple-pfSense-BridgeI really don't want to make you guys busy with my nonsense because I am already so glad that you all took the time to give me some advise about do's and dont's.
Anyway, wouldn't it be possible to bridge two interfaces in pfSense (one interface - managed Switch, other interface - dumb Wifi router) and add firewall rules on the bridge interface (like: block 192.168.5.1 -> 192.168.1.1 - 192.168.2.255)?
If so, should I really not go for such setup? It would make things much more easier. -
Dude you do not bridge interfaces and use different networks? 192.168.5, 192.168.2
In your example why would your iot devices not all be on the same layer 2 network? ie the same wifi network.. what devices are you using to control them - why wold they not be on the same wifi or layer 2 network via a wire?
Not seeing here why you think you have an issue?
"Most of the mobile apps which control these devices use UDP multicasts"
Why would you not just connect the device to that wifi network??
-
IMHO any "IoT" device that:
- Does not play nicely with IoT network isolation
- requires any inbound port forwards or special rules
should be promptly returned for a refund.
You might have some joy using a bridge with filters on the member interface but IoT is supposed to make life better/easier. And as johnpoz states, they would not be different layer 3 networks/subnets in that case.
-
Good point about returning the devices that don't support isolation.. I would agree!
I have not run into any iot devices that I can not isolate on their own layer 2 and 3.. None of my iot devices have access into any of my "normal" networks. I have access into them from my normal into them.. But there are no forwards from the outside into them either.
But I don't see any sort of issue that if you want to control some iot device with a mobile app just putting them on the same wifi network that would be 1 layer 2, and its own layer 3 and then isolating this network from the rest of your network(s)..
-
Any device that uses archaic discovery methods such as broadcast should also have some way to nudge/force it using DHCP, DNS, etc, else it should be returned.
mDNS/bonjour should be solvable with avahi, as has been stated.
