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

    pfSense and IPSEC lan to lan: a big doubt about the correct implementation

    Scheduled Pinned Locked Moved General pfSense Questions
    83 Posts 3 Posters 6.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.
    • M
      mauro.tridici @stephenw10
      last edited by mauro.tridici

      @stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:

      I assume that the actual WAN interfaces here are not set to 9000 MTU?
      If you are pinging with 9000B packets they must be fragmented.
      In your test setup was anything set to 9000 or was it all at the default 1500?

      @stephenw10 said in pfSense and IPSEC lan to lan: a big doubt about the correct implementation:

      I assume that the actual WAN interfaces here are not set to 9000 MTU?

      Yes, it is set to 1500 MTU

      If you are pinging with 9000B packets they must be fragmented.

      Ok, thanks

      In your test setup was anything set to 9000 or was it all at the default 1500?

      Yes, in my previous test setup LAN 1 at site A and LAN at site B were at 9000.

      You can find below the schema with the MTU settings for each involved interface

      schema.jpeg

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Ok, so one significant difference here is that in the production setup, where pfSense-A is behind NAT, it's WAN is using MTU 9000 and in the test setup it would have been 1500, correct?

        That means the IPSec traffic is likely being fragmented by router A rather than any large packets being fragmented in pfSense before being sent over the tunnel.

        Since that interface also has to accept the internal connections setting it to MTU 1500 might cause other problems though.
        You might try testing from a client set to 1500. Or set an MSS value on the tunnel to be sure TCP packets are not fragmented:
        https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#mss-clamping

        M 1 Reply Last reply Reply Quote 1
        • M
          mauro.tridici @stephenw10
          last edited by

          @stephenw10

          You really helped me to solve the issue.
          Now the iperf bitrate is about 912 Mbit/s and the throughput captured during a test data transfer between the two LANs is about 102 MB/s.

          I changed the MSS value on the LANs interface on each pfsense instance and I tuned Tcp window parameters in both the hosts involved (hosts at LAN A and LAN B).

          Thank you for your help and patience.
          Have a great day,
          Mauro

          1 Reply Last reply Reply Quote 1
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            That's great news.

            Did you try setting the MSS value for the tunnel only? Or did you need to set it on the interfaces?

            Be good to know for anyone else hitting that issue.

            Steve

            M 1 Reply Last reply Reply Quote 0
            • M
              mauro.tridici @stephenw10
              last edited by mauro.tridici

              Good morning Steve,

              I set the MSS values only for the LAN A and LAN B interfaces on each pfsense instance (please, take a look at the orange circles). Does it make sense in your opinion?
              It made VPN working with an acceptable (but still low) throughput 380Mbit/s.

              update07.jpeg

              In my case, hosts tuning has been the most important things to do to increase the iperf test results. TCP window, TCP buffer (rmem and wmem), SACK and so on...

              Now, everything seems to be ok, but I have to apply some traffic shaping on the IPSEC tunnel 😁 . Is there some guide about this procedure?

              Have a great day,
              Mauro

              1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator
                last edited by

                Ah, traffic shaping is a whole new topic! There are many many variables there.
                https://docs.netgate.com/pfsense/en/latest/trafficshaper/index.html

                Firstly what issue are you trying to address with shaping?

                Steve

                M 1 Reply Last reply Reply Quote 1
                • M
                  mauro.tridici @stephenw10
                  last edited by

                  @stephenw10

                  Do you prefer I home a new topic?
                  I'm trying to limit the IPSEC tunnel bandwidth to about 90% (or to 80MB/s).

                  Thank you,
                  Mauro

                  1 Reply Last reply Reply Quote 0
                  • stephenw10S
                    stephenw10 Netgate Administrator
                    last edited by

                    Just a hard limit to allow other traffic outside the tunnel?

                    M 1 Reply Last reply Reply Quote 0
                    • M
                      mauro.tridici @stephenw10
                      last edited by

                      @stephenw10

                      Mmmh, just a way to limit the traffic through the tunnel.
                      Now, the IPSEC tunnel has a very good throughput and I already know that users will saturate this channel with their data transfer sessions from LAN at site A to LAN at site B.

                      1 Reply Last reply Reply Quote 0
                      • stephenw10S
                        stephenw10 Netgate Administrator
                        last edited by

                        Then I would use a Limiter outbound on the IPSec interface at either end.

                        https://docs.netgate.com/pfsense/en/latest/trafficshaper/limiters.html

                        You could also apply that inbound on the source interface if that's known at both ends. Either way it's better to limit at the sending end than receiving.

                        Steve

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