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

    Can't ping from VLAN interfaces/devices can't ping PFSense

    Scheduled Pinned Locked Moved General pfSense Questions
    3 Posts 2 Posters 1.7k 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.
    • J Offline
      jdp0418
      last edited by

      I am having a strange issue with a PFSense build.  Running the latest 2.2.4 NanoBSD release.

      I have VLAN trunking setup to a Cisco 2960 switch.  Devices on the VLANs can ARP, get out to the internet and appear to be working normally.  However, those devices cannot ping the IP on the PFSense.  Rules are definitely in place to allow ICMP traffic to the firewall, and even more confusing is the fact that the PFSense itself cannot ping any devices in any of the VLANs.

      If I monitor my Ethernet port on the PFSense and attempt to ping a device in the ARP table, I don't even see PFSense attempting to send ICMP out the interface.

      I know the PFSense will capture its ICMP traffic because I can capture when I ping out the WAN.

      17:27:39.672327 IP x.x.x.x > 8.8.8.8: ICMP echo request, id 41324, seq 0, length 64
      17:27:39.699102 IP 8.8.8.8 > x.x.x.x : ICMP echo reply, id 41324, seq 0, length 64
      17:27:40.678092 IP x.x.x.x  > 8.8.8.8: ICMP echo request, id 41324, seq 1, length 64
      17:27:40.701743 IP 8.8.8.8 > x.x.x.x : ICMP echo reply, id 41324, seq 1, length 64
      17:27:41.681067 IP x.x.x.x  > 8.8.8.8: ICMP echo request, id 41324, seq 2, length 64

      I confirmed I am receiving ICMP requests on the VLAN interfaces.

      17:34:20.075089 IP 192.168.126.53 > 192.168.126.11: ICMP echo request, id 1, seq 10, length 40
      17:34:28.292969 IP 192.168.126.53 > 192.168.126.11: ICMP echo request, id 1, seq 11, length 40
      17:34:33.168198 IP 192.168.126.53 > 192.168.126.11: ICMP echo request, id 1, seq 12, length 40
      17:34:38.168584 IP 192.168.126.53 > 192.168.126.11: ICMP echo request, id 1, seq 13, length 40
      17:34:43.173505 IP 192.168.126.53 > 192.168.126.11: ICMP echo request, id 1, seq 14, length 40
      17:34:48.173616 IP 192.168.126.53 > 192.168.126.11: ICMP echo request, id 1, seq 15, length 40

      I found this post, first entered in June 2014 and last updated several weeks ago.  I attempted the solution posted with no success.  There is also no mention of the versions being used there. 
      https://forum.pfsense.org/index.php?topic=78414.0

      I can post more info on my config, but traffic seems to be working, but PFSense's ability to send and respond to ICMP traffic on VLAN Tagged interfaces doesn't appear to be working.

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

        You'll have to show us what you've done because if it was right it would be working.  Pick a VLAN and show us the interface config, firewall rules, etc.

        Maybe the switch port config in the 2960 too.

        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
        • J Offline
          jdp0418
          last edited by

          Yup, you're correct.  If it was done right, it would be working.

          Turns it was an IPSEC phase 2 configuration conflict.  I had one of my techs build the tunnels and he decided to use a /16 to summarize the 192.168.0.0 networks in the phase 2 entry.  So the firewall was trying to IPSEC everything.  Fixed the CIDR notation to get away from the networks in use locally on the firewall and all is well now.

          So yeah, you know, just configure things correctly and things will work…  :D

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