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

    One SYN packet 2 SYN-ACK replies

    Routing and Multi WAN
    4
    13
    6.5k
    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
      thierry_zoller
      last edited by

      Dear Community,

      I have a multi.homed setup. LAN, PPPOE, Leased Line.  I do the leased with briding with lan (and applying filters) and every DHCP address (LAN) goes out over PPPoE.

      I have the following problem : (I use HPING in this example to show you )

      A single SYN packet  gives 2-3  SYN-ACKS delayed by 3-6 seconds back :

      –---------------------------------------------------------------------------------------
      Here are the replys to SYN packets to port 443
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA **seq=**0 win=5840 rtt=26.4 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=1 win=5840 rtt=25.5 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=2 win=5840 rtt=24.6 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=3 win=5840 rtt=23.9 ms
      DUP! len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=0 win=5840 rtt=3025.3 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=4 win=5840 rtt=25.0 ms
      DUP! len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=1 win=5840 rtt=3626.4 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=5 win=5840 rtt=24.9 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=6 win=5840 rtt=24.3 ms
      DUP! len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=2 win=5840 rtt=4426.0 ms
      len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=7 win=5840 rtt=25.5 ms
      DUP! len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=3 win=5840 rtt=4026.7 ms
      DUP! len=46 ip=194.154.210.xx ttl=58 DF id=0 sport=443 flags=SA seq=4 win=5840 rtt=3625.4 ms

      –---------------------------------------------------------------------------------------

      I crosschecked on another line and it is definately not the problem of the host. Is somebody aware what could be the
      problem ?       I really tried nearly everything ( disabled the firewall, disabled a few filters etc)

      I can post the config.xml if desired.

      Thanks!

      1 Reply Last reply Reply Quote 0
      • S
        sullrich
        last edited by

        Very interesting.

        I have forwarded this info onto the Bridge maintainer on FreeBSD.

        In the meantime, try this from a shell then hping again:

        sysctl net.inet.tcp.delayed_ack=0

        1 Reply Last reply Reply Quote 0
        • T
          thierry_zoller
          last edited by

          I executed the command as referenced above :

          sysctl net.inet.tcp.delayed_ack=0

          net.inet.tcp.delayed_ack: 0 -> 0

          The result with HPING are exactly the same, please note that this ONLY is a problem over the PPPoE connection and not over the bridged leased line.

          Thanks!
          Thierry

          1 Reply Last reply Reply Quote 0
          • T
            thierry_zoller
            last edited by

            I found an interesting condiditon, when HPINGING google.com all packets are fine, no double packets, the difference I saw is that google.com has IP ID sequences as were my targets had DF bit set and IPID = 0. This could be interesting, maybe packet fragementat pfsense can't handle correctly ?

            Thierry

            1 Reply Last reply Reply Quote 0
            • S
              sullrich
              last edited by

              Thanks for the update, I'll send it over to Andrew.

              1 Reply Last reply Reply Quote 0
              • T
                thompsa
                last edited by

                Its true that the bridge code does not do any fragmentation, this will be addressed soon.

                1 Reply Last reply Reply Quote 0
                • T
                  thierry_zoller
                  last edited by

                  Thanks for your comments, but this ain't on the bridge or am I missing something ?  ???

                  1 Reply Last reply Reply Quote 0
                  • S
                    sullrich
                    last edited by

                    Please try beta 3.

                    1 Reply Last reply Reply Quote 0
                    • T
                      thierry_zoller
                      last edited by

                      I did just upgrade and checked the new option to "Clear DF bit instead of dropping"

                      This gave me the following error :

                      There were error(s) loading the rules: /tmp/rules.debug:15: random-id cannot be respecifiedpfctl: Syntax error in config file: pf rules not loaded - The line in question reads [15]: scrub on ng0 all no-df random-id max-mss 1452 random-id…

                      The standard Beta 3  (without this option) gives the same results  :(

                      Thanks for your support

                      1 Reply Last reply Reply Quote 0
                      • H
                        hoba
                        last edited by

                        Already fixed. Unchecking this option shouldn't give this error though. Apply http://pfsense.bol2riz.com/updates/pfSense-BETA3-update-for-random_id-and-blank_rule-issues-on-embedded-and-full.tgz

                        1 Reply Last reply Reply Quote 0
                        • T
                          thierry_zoller
                          last edited by

                          Thank you,

                          The rule installed fine now, the DF bit is removed an IPID is added, however the problem with duplicates packets remains, maybe it's my config that is really at fault?

                          len=46 ip=194.154.210.xx ttl=58 id=28123 sport=443 flags=SA seq=0 win=5840 rtt=26.4 ms
                          len=46 ip=194.154.210.xx ttl=58 id=343 sport=443 flags=SA seq=1 win=5840 rtt=25.5 ms
                          len=46 ip=194.154.210.xx ttl=58 id=7653 sport=443 flags=SA seq=2 win=5840 rtt=24.6 ms
                          len=46 ip=194.154.210.xx ttl=58 id=23457 sport=443 flags=SA seq=3 win=5840 rtt=23.9 ms
                          DUP! len=46 ip=194.154.210.xx ttl=58 id=23457  sport=443 flags=SA seq=0 win=5840 rtt=3025.3 ms

                          Interesting is here that the duplicate packet has another IPID as the original, this is most likely due to PF adding the value, right ?

                          1 Reply Last reply Reply Quote 0
                          • T
                            thierry_zoller
                            last edited by

                            Quick note:

                            If I disable the "Remove DF bit" in the advanced settings, the DF bit is now set but an IPID is added (i suppose by PF), before this option there was no DF and no IPID (no need to since DF)  is this intented behaviour ? As i use Pfsense for Pentests I would ideally need 1:1 packets (so that the results are not falsified)

                            1 Reply Last reply Reply Quote 0
                            • T
                              thierry_zoller
                              last edited by

                              Dear Group,
                              I appreciate your help, I am still having the same issue I can't seem to resolve, duplicate SYN ACKS  ???
                              Anyway my rules could be at fault ?

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