• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
Netgate Discussion Forum
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login

LAN1 can access computers but not managed switch on LAN2

Scheduled Pinned Locked Moved Firewalling
5 Posts 3 Posters 583 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.
  • T
    TD22057
    last edited by Feb 1, 2019, 3:02 AM

    Most likely I'm doing something stupid here but I'm stumped and am looking for ideas. I recently picked up an Aruba S2500 L3 switch (48 gigabit POE ports + 4 10GB ports for $100 - couldn't resist) and I'm experimenting with it to see how it works and how I should use it. Right now, it's running in L2 mode only. I have a pfSense box with a WAN and 2 LANS:

    • LAN 1 (static IPv4, 192.168.1.0/24) connected to an unmanaged switch and PC1 at 192.168.1.100
    • LAN 2 (static IPv4, 192.168.2.0/24) connected to the managed switch at 192.168.2.2.
    • VLAN10 (static IPv4, 192.168.10.0/24) is configured in the switch (with an IP of 192.168.10.2) and pfSense (attached to LAN2 and with DHCP). PC2 is connected to a VLAN10 port on the switch.
    • The uplink port on the switch is set to trunk mode and is set to native and default VLAN1 and passing any VLAN.

    0_1548990041657_network.png

    Firewall rules on each interface are:

    • LAN1: IPv4/6, src=LAN1, *, *, *, *
    • LAN2: IPv4/6, src=*, *, *, *, *, *
    • VLAN10: IPv4/6, src=*, *, *, *, *, *

    PC2 uses DHCP to get an address in VLAN10 just find. PC1 and PC2 can see each other and exchange data (iperf worked in client and server mode with each). PC2 can access the switch at 192.168.10.2 and pfSense at 192.168.10.1 or 192.168.1.1.

    The problem is that PC1 can't ping the managed switch or access it's web interface at 192.168.2.2. In the long run everything is going to move under that switch so it doesn't really matter but it seems weird. Could it be some config issue with the trunk connection between pfSense and the switch? I have a hard time seeing how this is a pfSense issue but I've got zero experience with this kind of set up so I'm guessing it's something obvious.

    Any ideas would be greatly appreciated.

    K 1 Reply Last reply Feb 2, 2019, 7:39 PM Reply Quote 0
    • K
      Konstanti @TD22057
      last edited by Feb 2, 2019, 7:39 PM

      @td22057
      Hey
      See this link
      Maybe that answers your question.
      And why it is not recommended to use vlan1 on the trunk port

      https://www.netgate.com/docs/pfsense/book/vlan/vlans-and-security.html

      1 Reply Last reply Reply Quote 0
      • S
        stephenw10 Netgate Administrator
        last edited by Feb 2, 2019, 7:48 PM

        Can anything ping or open 192.168.2.2? PC1, PC2 or pinging from pfSense itself?

        In Diag > Ping in the pfSense GUI you can choose the source IP. If you choose 192.168.2.1can it ping 192.168.2.2?

        If yes try a different source IP there. You could have a bad subnet mask or no default route set on the switch so it can only respond to devices inside it's own subnet.

        Steve

        1 Reply Last reply Reply Quote 0
        • T
          TD22057
          last edited by TD22057 Feb 2, 2019, 8:29 PM Feb 2, 2019, 8:29 PM

          Thanks @Konstanti. I ran across that last night and changed it around this morning. I created a management VLAN, moved the switch to that, and have it grab a DHCP address from pfsense on the management VLAN. That way nothing is on the 192.168.2.x subnet. I just finished testing it before lunch and everything is now working as expected. I'm not sure what the underlying issue was but this set up is better anyway (explicit management VLAN subnet) so I'm just glad it's working.

          1 Reply Last reply Reply Quote 0
          • S
            stephenw10 Netgate Administrator
            last edited by Feb 2, 2019, 8:36 PM

            Yeah better to avoid tagged and untagged traffic on the same interface if you can because of exactly this sort of issue.

            There's no reason why it shouldn't work but I suspect the switch was not doing the expected thing with the untagged traffic.

            Steve

            1 Reply Last reply Reply Quote 0
            5 out of 5
            • First post
              5/5
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
              This community forum collects and processes your personal information.
              consent.not_received