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

    IPv6 Allow rule for "LAN subnet" fails with large packets; ok with "Any"

    Scheduled Pinned Locked Moved Firewalling
    2 Posts 2 Posters 1.9k 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
      JackTripper
      last edited by

      i was testing Path MTU discovery packet sizes, and was pinging the pfSense machine over IPv6; finding the largest packet i could get away with.

      The largest IPv6 ICMP payload was 1452 bytes: ping -6 -l 1452 fe80::1:1 -t

      This makes sense because:

       1,452 bytes payload
      +    8 byte ICMP header
      +   40 byte IPv6 header
      = 1500 bytes
      

      And i can see the packets arrive at the pfSense machine using tcpdump on pfSense:

      IP6 fe80::95f6:1c87:6da5:c5fd > fe80::1:1: ICMP6, echo request, seq 915, length 1460
      IP6 fe80::1:1 > fe80::95f6:1c87:6da5:c5fd: ICMP6, echo reply, seq 915, length 1460
      
      

      Now i wanted to test pfSense's ability to send ICMPv6 Packet Too Big (Type 2) if the packet is too big, and i bumped up the ping payload size by one byte: ping -6 -l 1452 fe80::1:1 -t

      This will result in a IPv6 packet that is 1501 bytes long; too big. As expected, i did not get an ping response; but i didn't notice any Packet too big notifications. I used TcpDump on the client to see if i was receiving the required ICMP packets. I tried disabling the local firewall. I never saw them.

      I checked TcpDump on pfSense, to see if it was sending them. And there, paradoxically i was seeing two packets that made up the single ICMP echo request from the client:

      
      IP6 fe80::95f6:1c87:6da5:c5fd > fe80::1:1: frag (0|1448) ICMP6, echo request, seq 1034, length 1448
      IP6 fe80::95f6:1c87:6da5:c5fd > fe80::1:1: frag (1448|13)
      
      

      But i was not seeing any echo reply, nor was i seeing any ICMP Packet too big notification. I wondered if perhaps it was a firewall rule that was blocking Packet too big errors. But there couldn't be; i already had a rule:

      • Interface: LAN

      • TCP/IP Version: IPv6

      • Protocol: any

      • Source: LAN subnet

      For completeness, i tried changing the Source from LAN subnet to any:

      And suddenly, spontaneously (after applying the changes), my continuous pings that had been failing were suddenly getting valid ICMP echo responses:

      IP6 fe80::95f6:1c87:6da5:c5fd > fe80::1:1: frag (0|1448) ICMP6, echo request, seq 1156, length 1448
      IP6 fe80::95f6:1c87:6da5:c5fd > fe80::1:1: frag (1448|13)
      IP6 fe80::1:1 > fe80::95f6:1c87:6da5:c5fd: frag (0|1448) ICMP6, echo reply, seq 1156, length 1448
      

      My question contains a lot of setup; and what i was doing isn't really important. While i was confused (and still am) by Windows' decision to fragment IPv6 ICMP packets, the fact that it was fragmented shouldn't affect the pfSense firewall rule.

      How can changing the IPv6 Source option from LAN subnet to any make a difference? Why did it start working?

      1 Reply Last reply Reply Quote 0
      • R Offline
        razzfazz
        last edited by

        My guess is that "LAN subnet" does not include link-local addresses.

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