VLAN access port and transparent WAN bridge to VLAN
-
Hello all,
Please help me with the following two questions:
1: Create a VLAN access port on pfSense (Netgate 6100).
2: Create a transparent link between the Private WAN and one of the VLANs.In detail:
Internet access is provided by a double NAT setup consisting of a Netgate 6100 (NG6100) pfSense router attached to an ISP router (from Orange telecom in France).
Behind the NG6100 is a private network (LAN) that holds only Unify network gear. The network trunk between the NG6100 consists of a default LAN and about a dozen VLANs (with IDs 1xx) as shown below (please excuse my limited drawing skills):
[Internet]
^
| Public WAN
v
[ISP router]
^
| Private WAN (192.168.1.0/24)
v
[NG6100]
^
| trunk port = Private LAN (192.168.11.0/24) & VLANs (192.168.1xx.0/24)
v
[Unified Switch]
^
︙The LAN port acts as the VLANs' parent port. All are defined as lan interfaces (default gateway, DNS and DHCP server) at the router.
The Unify system refers to them as "3rd party router"-based and only plays a layer 2 role (no layer 3 routing switch). Everything works flawlessly.
In the following, the term "transparent" will refer to a link that appears to the two end nodes as a pure layer 2 link and has no apparent routing side effects.
Q1: Create an interface assigned to a port, Px, on the router, such a connected computer has direct/untagged and transparent access to one of the private VLANs, like so:
︙
v
[_NG6100_______________________Px]
^ ^
| trunk port = LAN & VLANs | Untagged access port for VLANx
v v
[Unified Switch] [Computer]
^ ^
︙ | VLANxIdeally, the computer would be on the VLAN's subnet.
Q2: Create a transparent link/channel from the Private WAN and a device connected to one of the Private VLANs. The IPS' router acts as video streaming gateway and ISP video players seem to only work if they are directly connected to their own routers. Pulling an extra wire or using Wi-Fi is not possible due to the physical distance. This would look like so:
︙
v
[ISP router with video streaming] believes video player is connected to Private WAN
^
| Private WAN
v
[NG6100]
^
| trunk port = Private LAN & VLANs
v
[Unified Switch]
^ ^
︙ | VLAN_video
v
[video player]I have tried to solve these problems, but to no avail. I was able to successfully create a transparent bridge between the Private WAN and one of the available NG6100 ports and another one between the private LAN and a NG6100 port, but do not know how to connect this to one of the private VLANs without creating significant side effects.
Any help provided will be greatly appreciated.
Thanks,
Peter -
@peter1879 said in VLAN access port and transparent WAN bridge to VLAN:
I was able to successfully create a transparent bridge between the Private WAN and one of the available NG6100 ports and another one between the private LAN and a NG6100 port
You should need only one bridge between the WAN and the "video VLAN". But at first remove the IP settings from the VLAN interface.
Then add firewall rule to the interfaces to pass the desired traffic. -
@viragomann Thank you for your advice. This is in line with what I found out so far.
In more general terms, here is what I found:
1: It is possible to create a bridge between a tagged VLAN interface and an untagged LAN interface just like between two untagged interfaces, except if the tagged VLAN's parent interface is also a member of a bridge. See here for more: https://redmine.pfsense.org/issues/11139. For example, if LAN on ix0, VLAN10 on ix0.10 and LAN2 on ix1, then I can create a bridge between VLAN10 and LAN2 if, and only if, LAN is not a member of a bridge.
2: This bridging works well between a WAN interface and a VLAN, which itself is bound to a LAN parent interface. To use the example above, this would be between the WAN interface and LAN10. In my case, where the WAN is a "private WAN" behind an Internet facing gateway (ISP-GW), the Netgate's WAN interface (like any other member interface) can be configured to receive an IP address via DHCP (but not have a DHCP server) from the ISP-GW (192.168.192.0/24). All other devices connected to this bridge will also be able to receive an IP address from ISP-GW. Note that all addresses on member interfaces and all connected devices are (must be) in the same subnet. Also note that, generally, this does not work without the double NAT/gateway setup, because it would need multiple IP addresses from the ISP.
3: For DHCP address assignment to work, a firewall rule may be required on all bridge member interfaces (except probably the one where the DHCP server resides): source 0.0.0.0, source port 68, destination address 255.255.255.255 and destination port 67. This message is the first to be sent in the DHCP protocol. There are two aspects to this that I don't fully understand yet:
3.1: The rule may not be required if one of the bridge member interfaces receives a DHCP address. It seems that pfSense automatically adds a hidden rule to that effect. What is not clear to me is whether this hidden rule applies only to the bridge member that receives a DHCP address, or whether it applies to all bridge members.
3.2: I don't understand the role of the system tunables net.link.bridge.pfil_bridge and net.link.bridge.pfil_member. It is easy to find a variety of explanations for these, but none of these is complete. There are two aspects of firewall rules in brides and bridge members: a) govern the traffic between the bridge interface or a member interface entering/exiting the firewall/routing engine, and b) filtering the traffic between the member interfaces without it entering the firewall. I suspect the system tunables apply to the first aspect, but not to the second.
3.3: Testing of this is complicated by the facts that a) devices cache their IP address and use the last address when trying to renew an address lease, and b) the bridge caches the MAC addresses on each bridged segment. When changing the firewall rule mentioned above and the system tunable settings, all the caches need to be flushed to determine the impact of the change.
4: Concerning the propagation of the traffic on the Unifi switches (and I assume this is similar to other managed switches): to make this work the only thing required is to declare the VLAN, without specifying DHCP/seubnet/gateway parameters. This makes the switch aware that the VLAN exists. The VLAN can then be added to trunk profiles (as tagged traffic) and to port profiles for VLAN-unaware end nodes' access to the untagged data stream.
I will further update this when I have gained a better understanding for 3.2.
Any further comments are welcome.
Peter