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

    IPSec/VTI/BGP: MSS clamping on VPN traffic

    IPsec
    3
    10
    2.0k
    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.
    • O
      oyermolenko
      last edited by

      a few words about my environment:
      corporate IPSec VPNs using /30 VTI interfaces which also are used for BGP peerings.

      Just want to clarify how to define corporate VPN networks to use MSS clamping?

      small research:

      grep scrub /tmp/rules.debug

      scrub from any to <vpn_networks> max-mss 1360
      scrub from <vpn_networks> to any max-mss 1360
      scrub on $WAN all    fragment reassemble
      scrub on $LAN all    fragment reassemble
      

      reviewed filter_generate_scrubing and filter_get_vpns_list functions (/etc/inc/filter.inc)

      discover that there is a special table called vpn_networks.
      But found nothing how this table will be filled in my case (VTI/30). That is why I forced to keep fake and disabled P2 for IPsec near with VTI P2 (keep in mind [1]).

      I don't want to edit /etc/inc/filter.inc and change <vpn_networks> for example to manually created by WebUI <crp_vpn_networks> alias. (this changes will be lost during the next upgrade). Also I guess bug #7622 finally will be fixed [1]

      the main questions: how to fill the special table <vpn_networks> in order to avoid future upgrade?
      What is it right way?

      Oleksandr

      [1] https://redmine.pfsense.org/issues/7622

      P.S. tried to write custom script, but without success.

      cat /usr/local/pkg/custom_scrub_rules.inc

      <?php
      require_once("util.inc");
      
      function custom_filter_generate_scrubing() {
              $scrubrules = "";
              $crp_maxmss = 1360;
      
              $scrubrules .= "scrub from any to <crp_vpn_networks> max-mss {$crp_maxmss}\n";
              $scrubrules .= "scrub from <crp_vpn_networks> to any max-mss {$crp_maxmss}\n";
      
              return $scrubrules;
      }
      ?>
      
      K 1 Reply Last reply Reply Quote 0
      • K
        Konstanti @oyermolenko
        last edited by Konstanti

        @oyermolenko

        Hey
        But why would the interface VTI change the mss ?
        by default, this interface is created with mtu=1400 (mss 1360)

        #define	IPSEC_MTU		       1400
        #define	IPSEC_MTU_MIN		1280
        #define	IPSEC_MTU_MAX		8192
        ifp->if_mtu = IPSEC_MTU;
        ifp->if_flags  = IFF_POINTOPOINT | IFF_MULTICAST;
        	
        
        
        [2.4.4-RELEASE][admin@pfSense.localdomain]/root: ifconfig ipsec2000
        ipsec2000: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> metric 0 mtu 1400
        

        you can change the mtu or mss in the VTI interface settings

        the <vpn_networks> table is used for other purposes

        1 ipsec mobile client
        2 ipsec in tunnel mode site to site connection
        3 openvpn

        1 Reply Last reply Reply Quote 0
        • O
          oyermolenko
          last edited by oyermolenko

          Yes, @Konstanti , you are right, VTI interfaces with MTU 1400

          But despite of this fact I have the issue related to MSS/MTU.
          pfsense-VTI.png

          2.4.4-RELEASE-p3

          K 1 Reply Last reply Reply Quote 0
          • K
            Konstanti @oyermolenko
            last edited by Konstanti

            @oyermolenko
            Hey
            try to reduce the mss in the settings of the VTI interface

            30c582da-80e4-4e33-b902-dd62ccc20d1d-image.png

            1 Reply Last reply Reply Quote 0
            • O
              oyermolenko
              last edited by

              the main my problem is very small performance. 100-300KB. I was trying to change interface settings according to the mentioned in the previous @Konstanti reply. Without success.
              But frankly speaking I'm not sure that tcpdump was created with these recommendations.

              K 1 Reply Last reply Reply Quote 0
              • K
                Konstanti @oyermolenko
                last edited by Konstanti

                @oyermolenko

                try to reduce the mss to 1300 ( mtu 1340)
                in February-March this year there was a topic where it helped

                1 Reply Last reply Reply Quote 0
                • O
                  oyermolenko
                  last edited by

                  decreased to 576 :-(

                  K 1 Reply Last reply Reply Quote 0
                  • K
                    Konstanti @oyermolenko
                    last edited by

                    @oyermolenko

                    Try changing on both sides of the tunnel.

                    https://forum.netgate.com/topic/140649/ipsect-site-to-site-slow-upload-fast-download-issue/21

                    1 Reply Last reply Reply Quote 0
                    • O
                      oyermolenko
                      last edited by oyermolenko

                      nowadays just keep disabled P2 with needed nets for scrubbing.

                      1 Reply Last reply Reply Quote 0
                      • B
                        bruor
                        last edited by

                        I recently got hit with this, couldn't run remote backups of my switches via SSH over a VTI tunnel after switching from site to site.

                        I noticed that entering 1400 in both the MTU and MSS for the interface resulted in a scrub for max-mss to 1360 which seems to be correct. Not sure why pfsense auto deducts 40 from the MSS, since MSS should be 40 less than MTU already.

                        Using 1400 in both fields on both ends of the links has resolved my issues here.

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