Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login
    Introducing Netgate Nexus: Multi-Instance Management at Your Fingertips.

    [SOLVED] Multiple VLAN Issues

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 2 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C Offline
      calix0817
      last edited by

      I have pfSense 2.1.5 (amd64) running in VMWare ESXi 5.5 connected to a Cisco SG200-26 switch.  The following 3 VLANs are currently defined in pfSense:

      Server Network - VLAN 100 - 10.52.0.0/23
      Management Network - VLAN 112 - 10.52.12.0/23
      Guest Network - VLAN 203 - 192.168.203.0/24

      DHCP is enabled on all VLANs and the address for pfSense on each VLAN is x.x.x.1.  Here comes the fun part:

      Server Network:

      • Can get DHCP Address

      • Can access internet

      • Can ping anything on Server Network

      • Can ping anything on Guest Network

      • Can't ping anything on Management Network

      Management Network:

      • Can get DHCP Address

      • Can access internet

      • Can't ping gateway (pfSense) at 10.52.12.1

      • Can ping everything else on Management Network

      • Can't ping anything on Server Network

      • Can ping anything on the Guest Network

      Guest Network:

      • Can get DHCP Address

      • Can access internet

      • Can ping anything on any Network

      There is only 1 firewall rule on each network that is allowing all traffic.  I am expecting all configured VLANs to function like the Guest Network with the current configuration.  What could be happening to cause the Server and Management VLANs to not talk to each other?  The only devices on the Management network are:  pfSense (10.52.12.1), the switch (10.52.12.6), and a laptop for testing the VLAN.

      1 Reply Last reply Reply Quote 0
      • DerelictD Offline
        Derelict LAYER 8 Netgate
        last edited by

        Are you sure DHCP is assigning a 23-bit netmask to your clients where necessary?

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • C Offline
          calix0817
          last edited by

          Yes, I just double checked.  The clients in both the Server and Management Networks are getting a /23 netmask.

          1 Reply Last reply Reply Quote 0
          • DerelictD Offline
            Derelict LAYER 8 Netgate
            last edited by

            Well, double check everything.  This stuff just works.

            Start posting interface and firewall rule screen shots to get more eyes on what you're doing.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

            1 Reply Last reply Reply Quote 0
            • C Offline
              calix0817
              last edited by

              I found out the issue.  An ipsec subnet was overlapping with the new VLANs causing a routing issue.

              Stupid me for setting up the VPN before finishing the VLAN configurations. (And stupid parent company for forcing us to these new ip schemes and demanding a VPN while still using 10.0.0.0/8)

              Marking as solved.  Thanks.

              1 Reply Last reply Reply Quote 0
              • DerelictD Offline
                Derelict LAYER 8 Netgate
                last edited by

                @calix0817:

                10.0.0.0/8

                Seems I've heard that somewhere before.  10.0.0.0/8 is pure evil.

                Glad you found it.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post
                Copyright 2026 Rubicon Communications LLC (Netgate). All rights reserved.