VLAN(s) -2 TRUNK ports on diferent pfSense NICs



  • Hallo.

    I'm trying to figure out how to connect two managed switches with same VLANs to pfSense box and get VLANs working

    I have 3 VLANs:

    • LAN - 10
    • GUEST - 20
    • IOT -30

    Due my horrible house topology, I have 2 managed switches, each in different location. TRUNK ports from these switches will be connected to 2 NICs on pfSense box.

    Each switch must be able to handle all mentioned VLANs.

    • Switch1 is connected to igb1 interface on the pfSense
    • Switch2 is connected to igb2 interface on the pfSense

    I have tried to create VLAN interfaces (igb1.10, igb1.20, igb1.30, igb2.10.....) with parents igb1 and igb2.
    Then create three bridges, each for one VLAN:

    • bg_10 (igb1.10, igb2.10)
    • bg_20 (igb2.10 igb2.20)
    • bg_30 (igb2.30 igb3.20)

    Assign IP range to each bridge.
    Enable DHCP for bridges.

    But seems that this config doesn't work. DHCP leases are not assignd properly, etc..

    Can you please give me a hint, how to correctly set these VLANs on pfSense ?

    Thank you so much !



  • You link the switches together not the pfSense LAN ports.

    You could use ethernet over power devices, I have 3 x 8 port switches connected this way.



  • @zdenal Since you have 3 distinct lans, you also need different ip subnets and different rules.
    So forget about bridging.
    Assign interfaces to vlans, and then assign static ip's to interfaces and dhcp ranges and it will work.



  • @netblues

    Maybe I do not understand exactly what you means. I try extend my previous post to be more clean:

    • Switch1 is at my main house
    • Switch2 is at my garden house with workshop.

    between these locations is long distance...

    PfSense box is far away from both switches (third place where my ISP is providing WAN connection) and I'm able to get only one cable from each switch to pfSense...

    I can assign

    • LAN: 192.168.10.1/24
    • GUEST: 192.168.20.2/24
    • IOT: 192.168.30.1/24

    But for example living room thermometer and workshop thermometer have to be both on IOT VLAN, with IPs from 192.168.30.0/24 range - assigned by dhcp
    SAme for LAN when my PC in bedroom have to be connected with NAS in garden house with IPs from 192.168.10.0/24 range.

    I need functional broadcast on each VLAN for all devices.

    The question is, how correctly connect switch1 and switch2 to pfSense where all DHCP magic and routing to internet will be done...



  • So, are the switches managed ? (Yes they are)

    You need to create a trunk port (802.1q ) from each switch
    On the switch configuration you can have as many normal (untagged ports) belonging to relevant vlans..
    Then all needed vlans should be tagged on the trunk port to pf

    On pf you create the necessary vlans, and assign interfaces..
    These interfaces will function as if a direct cable has been run for each vlan.

    Assign dhcp ranges to each (sub) interface and you are good to go..
    straight forward



  • @netblues Yes, booth are managed. Sorry for unclear, i mention that i have TRUNK ports connexted to pfSense. Then, on each switch <--> pfSense box connection can be packets taged by appropriate VLAN10, VLAN210 or VLAN30.

    But problem is that bedroom PC will communicate by igb1 and NAS by igb2. Of course, taggged by PVID10...

    By other way, the easiest solution can be to buy third managed switch, connect wires from switch1 and switch2 by this main switch and connect this main switch to pfSense only by one wire.

    And I'm not sure if i can assign one DHCP to two different interfaces?

    But I belioeve that is not necessary to buy third device to do that, if my pfSense has free RJ ports... So i'm looking for solution.



  • @

    By other way, the easiest solution can be to buy third managed switch, connect wires from switch1 and switch2 by this main switch and connect this main switch to pfSense only by one wire.

    And I'm not sure if i can assign one DHCP to two different interfaces?

    But I belioeve that is not necessary to buy third device to do that, if my pfSense has free RJ ports... So i'm looking for solution.

    Why buy thrid switch?

    Pfsense can communicate with eg 30 switches with as many vlans over just one interface.



  • Now I see it
    you say
    I have tried to create VLAN interfaces (igb1.10, igb1.20, igb1.30, igb2.10.....) with parents igb1 and igb2.
    Then create three bridges, each for one VLAN:

    bg_10 (igb1.10, igb2.10)
    bg_20 (igb2.10 igb2.20)
    bg_30 (igb2.30 igb3.20)
    

    well the correct bridge interface would be

    bg_10(igb1.10 igb2.10)
    bg_20(igb1.20 igb2.20)
    bg_30(igb1.30 igb2.30)

    At least in theory this should work



  • Sorry for typpo in my first message. What you wrote:

    bg_10(igb1.10 igb2.10)
    bg_20(igb1.20 igb2.20)
    bg_30(igb1.30 igb2.30)
    

    Is exactly what i have set.

    But DHCP is lottery, sometimes succeeded, and then not, even i flush all arp tables on both sides.

    And I see ARP queries without reply on bridges, plus queries from another subnet...

    21:55:56.333906 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:55:57.328695 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:55:59.429761 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:56:00.333446 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:56:01.009962 ARP, Request who-has 192.168.11.100 tell 192.168.11.1, length 28
    21:56:01.319546 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:56:03.074120 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42

    Anyway, it's not stable solution :(



  • I’ll say it again, link the switches together.



  • @NogBadTheBad said in VLAN(s) -2 TRUNK ports on diferent pfSense NICs:

    I’ll say it again, link the switches together.

    Well. that is the common tried method, but I still see no reason for the other one not to work.

    @zdenal said in VLAN(s) -2 TRUNK ports on diferent pfSense NICs:

    Sorry for typpo in my first message. What you wrote:

    bg_10(igb1.10 igb2.10)
    bg_20(igb1.20 igb2.20)
    bg_30(igb1.30 igb2.30)
    

    Is exactly what i have set.

    But DHCP is lottery, sometimes succeeded, and then not, even i flush all arp tables on both sides.

    And I see ARP queries without reply on bridges, plus queries from another subnet...

    21:55:56.333906 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:55:57.328695 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:55:59.429761 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:56:00.333446 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:56:01.009962 ARP, Request who-has 192.168.11.100 tell 192.168.11.1, length 28
    21:56:01.319546 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42
    21:56:03.074120 ARP, Request who-has 192.168.22.1 tell 192.168.22.100, length 42

    Anyway, it's not stable solution :(

    I dont think this is a pf issue. Vlan separation is the responsibility of the switches.
    A bridge of two lans, with tagged frames at the wire level, can't leak traffic from OTHER vlans. If that was the case then no router on a stick config could also work reliably.
    Seeing traffic from other vlans on a bridge interface could also get you the same traffic on a non bridged interface config, on the same vlan.
    I have never tried this, but I'm tempted to actually try it
    Break it up in smaller steps
    Create just one bridge and see if you get "leak" requests.
    I suspect default vlan memberships on the switches. What make are the switches?


  • LAYER 8 Netgate

    Get a third switch to use as your "core" and connect pfSense to that. Connect the other two switches to the "core" switch.

    The switches in the SG-1100, SG-3100, or XG-7100 would be a good choice here. Any of those could handle the VLAN trunk links to the other two switches without any messiness like pfSense bridging.


Log in to reply