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

    Pfsense 2.0.1 don't fragment packets bigger than interface MTU

    Scheduled Pinned Locked Moved General pfSense Questions
    3 Posts 2 Posters 2.1k 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.
    • A
      Alx1m1K
      last edited by

      Hello. I noticed, that on my pfsense 2.0.1 box packets bigger than interface MTU just discarded instead of getting fragmented.
      For example: ping from one PC to another via switch works

      PS C:\Users\AlximiK> ping 172.30.1.50 -l 64000
      
      Обмен пакетами с 172.30.1.50 по с 64000 байтами данных:
      Ответ от 172.30.1.50: число байт=64000 время=2мс TTL=64
      Ответ от 172.30.1.50: число байт=64000 время=2мс TTL=64
      Ответ от 172.30.1.50: число байт=64000 время=2мс TTL=64
      Ответ от 172.30.1.50: число байт=64000 время=2мс TTL=64
      
      Статистика Ping для 172.30.1.50:
          Пакетов: отправлено = 4, получено = 4, потеряно = 0
          (0% потерь)
      Приблизительное время приема-передачи в мс:
          Минимальное = 2мсек, Максимальное = 2 мсек, Среднее = 2 мсек
      

      but from and to pfsense box it is a problem:

      PS C:\Users\AlximiK> ping 172.30.1.1 -l 2000
      
      Обмен пакетами с 172.30.1.1 по с 2000 байтами данных:
      Превышен интервал ожидания для запроса.
      Превышен интервал ожидания для запроса.
      Превышен интервал ожидания для запроса.
      Превышен интервал ожидания для запроса.
      
      Статистика Ping для 172.30.1.1:
          Пакетов: отправлено = 4, получено = 0, потеряно = 4
          (100% потерь)
      

      and

      [2.0.1-RELEASE][admin@midgard.home]/(33): ping -s 2000 172.30.1.50 
      PING 172.30.1.50 (172.30.1.50): 2000 data bytes
      ^C
      --- 172.30.1.50 ping statistics ---
      8 packets transmitted, 0 packets received, 100.0% packet loss
      

      Big incoming packets just counted as input errors

      [2.0.1-RELEASE][admin@midgard.home]/(34): netstat -I sge0
      Name               Mtu Network       Address              Ipkts Ierrs Idrop    Opkts Oerrs  Coll
      sge0              1500 <link#1>      00:1b:fc:56:f5:45 132139701    77     0 162022955     0     0
      sge0              1500 172.30.1.0    midgard             166601     -     -   136383     -     -
      sge0              1500 fe80:1::21b:f fe80:1::21b:fcff:        0     -     -        0     -     -</link#1>
      

      On both PCs MTU are 9K, on pfsense its 1500. How can I solve this problem? Please advise.

      1 Reply Last reply Reply Quote 0
      • C
        cmb
        last edited by

        An incoming frame larger than the interface MTU is indeed an error. Up the MTU and it'll pass it if it can.

        1 Reply Last reply Reply Quote 0
        • A
          Alx1m1K
          last edited by

          Ok, and what about outgoing frame, why this

          [2.0.1-RELEASE][admin@midgard.home]/(33): ping -s 2000 172.30.1.50 
          PING 172.30.1.50 (172.30.1.50): 2000 data bytes
          ^C
          --- 172.30.1.50 ping statistics ---
          8 packets transmitted, 0 packets received, 100.0% packet loss
          

          is not working? Shouldn't pfsense fragment the packet before sending it (like windows does)? 172.30.1.50 is a freebsd9 pc with 9K mtu on interface and frames are properly fragmented before they sent out.

          root@freebsd9-storage:/home/alximik# ping -S 172.30.1.50 -s 18000 172.30.1.20
          PING 172.30.1.20 (172.30.1.20) from 172.30.1.50: 18000 data bytes
          18008 bytes from 172.30.1.20: icmp_seq=0 ttl=128 time=1.270 ms
          18008 bytes from 172.30.1.20: icmp_seq=1 ttl=128 time=1.318 ms
          18008 bytes from 172.30.1.20: icmp_seq=2 ttl=128 time=1.248 ms
          18008 bytes from 172.30.1.20: icmp_seq=3 ttl=128 time=1.309 ms
          18008 bytes from 172.30.1.20: icmp_seq=4 ttl=128 time=1.237 ms
          ^C
          --- 172.30.1.20 ping statistics ---
          5 packets transmitted, 5 packets received, 0.0% packet loss
          round-trip min/avg/max/stddev = 1.237/1.276/1.318/0.032 ms
          

          ============================
          Checked the capture, the cause is big echo reply. It was pretty stupid. Please close this topic =)

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