Navigation

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

    TCP Spurious Retransmission

    NAT
    1
    5
    2410
    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.
    • N
      NicoKlinger last edited by

      Hello,

      I'm using pfsense to manage a virtual network which is connected to my local network via the pfsense virtual machine.
      There is a server with an web interface connected to the virtual network.
      The server (freeNAS) is configured to use the pfsense machine as the default gateway which indeed works.

      I defined a port forwarding rule to acces the web interface but unfortunately I can't acces it from my local network. And as far as I can tell it should work.
      When I look at the traffic via the pfsense packet capture tool then it seems that everything is working correctly.
      Which means that the incoming traffic on WAN (connected to my local network) gets redirected to the server and the port is also changed to the correct port. I also see the answers from the server which were redirected to my machine and the port is also correctly changed.
      I also checked if the port of the server is up with the port test diagnostic tool.

      I followed the nat troubleshooting guide but unfortunately it didn't helped.

      If someone has a clue where the problem might be, please tell me.

      My nat rule is as follows:
      Interface: WAN
      Source IP / Port: *
      Dest IP: WAN
      Dest Port: 44300
      NAT IP: IP of the server
      NAT Port: 443

      I tried difrent nat reflections and the filter roule was added.

      I am sorry for my bad writing but unfortunately english is not my firt language as you can see.

      Regards,
      Nico Klinger

      1 Reply Last reply Reply Quote 0
      • N
        NicoKlinger last edited by

        A litle update:

        I used wireshark on the client and I found something interresting. It seems that my pc doesn't realize that it got an answer. Here are some lines from wireshark:

        192.168.178.client 192.168.178.pfsense TCP 74 [TCP Spurious Retransmission] 46945→44300 [SYN] Seq=0 Win=29200 Len=0 MSS=1460 SACK_PERM=1 TSval=4560670 TSecr=0 WS=128
        192.168.178.pfsense 192.168.178.client TCP 74 [TCP Retransmission] 44300→46945 [SYN, ACK] Seq=0 Ack=1 Win=65535 Len=0 MSS=1460 WS=64 SACK_PERM=1 TSval=270914581 TSecr=4560670

        Here is a link to the capture file: https://www.cloudshark.org/captures/d5862e51e560

        I added a firewal rule to acces the webfrontend directly without nat but the result is the same.

        1 Reply Last reply Reply Quote 0
        • N
          NicoKlinger last edited by

          Another update:

          I ran another packet capture with more details and I saw something interresting. In the cpature it says: "checksum incorrect". Here is an example:

          22:16:03.750825 00:1b:78:5d:1d:41 > 54:a0:50:d4:f1:b7, ethertype IPv4 (0x0800), length 74: (tos 0x0, ttl 63, id 0, offset 0, flags [DF], proto TCP (6), length 60)
              10.133.7.10.443 > 192.168.178.23.34600: Flags [S.], cksum 0x847d (incorrect -> 0x3f8d), seq 3484865332, ack 3414054763, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val 2540446535 ecr 8354345], length 0

          I guess this is the ip header checksum. But I have no idea why it's wrong.

          According to wiresahrk the ip checksums are correct but the tcp checksums aren't.

          1 Reply Last reply Reply Quote 0
          • N
            NicoKlinger last edited by

            Another update:

            I added a virtual mashine to the virtual LAN network of pfsense. I could open the webinterface of freenas. I could see the wrong tcp checksums in that connection too. Well I guess the wrong checksums are there becouse of checksum offload.
            I also tested if the internet connection works and it didn't. But I could ping google.com which indicates me that there is something wrong with my pfsense configuration.

            1 Reply Last reply Reply Quote 0
            • N
              NicoKlinger last edited by

              I found the solution.

              In a virtual network there are no checksums. So what I had to do was to disable tcp checksum offloading.
              Here are the two sources with more information that I used:
              https://forum.pfsense.org/index.php?topic=88467.0
              https://serverfault.com/questions/581265/disable-tcp-checksum-offloading-on-kvm-virtual-network

              1 Reply Last reply Reply Quote 0
              • First post
                Last post

              Products

              • Platform Overview
              • TNSR
              • pfSense
              • Appliances

              Services

              • Training
              • Professional Services

              Support

              • Subscription Plans
              • Contact Support
              • Product Lifecycle
              • Documentation

              News

              • Media Coverage
              • Press
              • Events

              Resources

              • Blog
              • FAQ
              • Find a Partner
              • Resource Library
              • Security Information

              Company

              • About Us
              • Careers
              • Partners
              • Contact Us
              • Legal
              Our Mission

              We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

              Subscribe to our Newsletter

              Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

              © 2021 Rubicon Communications, LLC | Privacy Policy