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

    Can't ping VIP gateway and client

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    7 Posts 2 Posters 3.0k 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.
    • E
      Elegant
      last edited by

      Hi guys,
      I have a working VLAN 10 that uses CARP without issues. I am now trying to create a VLAN 20 but I've got a really strange issue: Client's on VLAN 20 are unable to ping the VIP or the master gateway (.1 and .2) and vice-versa but the master is still providing an IP through DHCP. In addition, the slave gateway is easily accessible and can be pinged both ways. Occasionally, the slave will provide the DHCP IP instead. Client's on VLAN 20 have been permitted access to the entire network (for the time being) but there is no change.

      I'm at a loss for what could lead to this as the settings between the interfaces appear to be correct and I have the VLAN 10 (which is working) as a reference. I'm not sure if my L3 switch can play any role in this but again my VLAN 10 is having NO issues under this setup.

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

        Post your VLAN20 rules.

        Where is VLAN20? Is it on a pfSense interface or is your L3 switch routing 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
        • E
          Elegant
          last edited by

          @Derelict:

          Post your VLAN20 rules.

          Where is VLAN20? Is it on a pfSense interface or is your L3 switch routing it?

          I've attached the rules (mind you they don't mean much right now). VLAN 20 has actually been created on XenServer and then passed as an interface to pfSense (since you can't create VLANs through xn devices on pfSense). It does obey the rules though; the disabled ActiveDirectory rule is working properly, I just created that allow anything rule in hopes of being able to communicate between the gateway and the client.

          As mentioned, there are two gateways using CARP and only the slave is accessible. The master and client cannot ping each other at all.

          Rules.png
          Rules.png_thumb

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

            No idea as to your topology. It would have helped if you had mentioned a hypervisor in your original problem description.

            The diagram in my signature exists in XenServer so it all works.

            What, exactly, do you have going on? Please be complete and specific.

            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
            • E
              Elegant
              last edited by

              I have two pfSense running on XenServer using CARP on all VLANs. All VLANs, 1 (native), 10 20, 30, 40 are made in XenServer and passed to pfSense as interfaces. My L3 switch is connected to the server via it's uplink ports. My current PC is running great on VLAN 10 via the L3 as well as XenServer on VLAN 1. I have since created a new VLAN (20) and am trying to add a client to it. The port on the switch is configured for VLAN 20 and is aware of the VLAN.

              VLAN 1 and 10 can easily ping the VLAN 20 gateways and VIPs (they are allowed to) but client's on VLAN 20 cannot ping the master pfSense or the VIP nor vice versa. Slave works fine though.

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

                Still can't picture it. Sorry. Don't know what you expect from the information presented.

                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
                • E
                  Elegant
                  last edited by

                  I decided to look at the physical components and have the following (brief) layout but I no longer think the issue is with pfSense hence the briefness:

                  pfSense VMs /w CARP (XenServer) -> Cisco L3 -> Netgear L2 -> Client
                  

                  Both pfSense VMs are accessible when connected to a VLAN 20 port on the L3 switch. Now the issue, when you get to the VLAN 20 port on the L2 netgear switch it's no longer possible to reach one of the two gateways on any VLAN. If this happens to be the Slave then the VIP and Master are reachable; if it happens to be the Master then only the Slave is reachable.

                  This is most likely an issue between the cisco and netgear switches and will require further investigation. I'm not sure if you have any insight Derelict but the issue is no longer as originally described.

                  EDIT: Upon even further investigation, it seems like the L2 is basically useless in this case. It has no clue how to handle the gateways correctly and does not come with any kind of SSH let alone HTTPS. Fun times…

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