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

    Poor IPSec performance

    Scheduled Pinned Locked Moved IPsec
    27 Posts 9 Posters 15.9k 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.
    • K
      kapara
      last edited by

      Couple of things….

      Why do you have 0.0.0.0/0 listed?

      Also it looks like you are using multiple subnets behind your pfsense.  Either try creating static routes or changing the LAN to /16.

      Net between pfs2 and Switch2 is 172.16.10.0/24
      Net between PC2 and Switch2 is 172.16.65.0/26

      Skype ID:  Marinhd

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

        I have 0.0.0.0/0 liste because I want all traffic encrypted between the two pfsense machines.

        1 Reply Last reply Reply Quote 0
        • K
          kapara
          last edited by

          Is this just a test or is this a prod enviroment?  Why are you directly connecting the 2 pfSense boxes to each other?  is this a point2point tunnel?  Do you want internet requests to go through the IPSEC tunnel?  Have you tried specifying the correct subnet rather than 0.0.0.0/0?  Did you modify the Outbound NAT?  You might be having a conflict with the built-in NAT trying to send anything not specified out the WAN rather than the ipsec tunnel.

          Skype ID:  Marinhd

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

            It is suppose to go in the production environment.

            The 2 pfsense boxes are connected via a L2 connection with the soul purpose of encrypting all traffic between them.

            I have tried only having the 172.16.10.0/24 net behind pfs2 and only 172.16.100.0/26 behind pfs1. With requests from one net to the other icmp goes through. No problem. I can telnet through. But if I do a "show log" on the switch I'm telnetting to it briefly starts and then comes to a halt. This is also true if I connect to a windows share. A small amount of traffic is being sendt and the nothing.

            Again all works without IPSec.

            Modyfied::

            I should also menthion that all packet filtering and NAT is turned off.

            I was thinking about "Bypass firewall rules for traffic on the same interface", " Block RFC1918 Private Networks" and "Block bogon networks:" options. Can they play a part?

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

              Another discovery I made right now is that when ever the length of an ESP packet is 1480 everything stops. The next line in a tcpdump is always a esp (in lower case). See also print out.

              Can it be the MTU in IPsec?

              13:00:47.407446 IP 192.168.42.2 > 192.168.42.1: ESP(spi=0x01e083a4,seq=0x3), length 1480
              13:00:47.407450 IP 192.168.42.2 > 192.168.42.1: esp

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

                I have now performed a ping test where I tried to increase the packet size. When a packet must be fragmented the problem appears.

                Does this make sense?

                Modifyed::

                The max packet size I can ping with and get an answer is 1410. This results in a ESP packet of 1476. Anything larger than that, results in a ESP packet of 1480 and no data is coming through.

                tcpdump -vv

                Does not go through:
                13:19:19.391590 IP (tos 0x0, ttl 64, id 21771, offset 0, flags [+], proto ESP (50), length 1500) 192.168.42.1 > 192.168.42.2: ESP(spi=0x045c0bdd,seq=0xa), length 1480
                13:19:19.391593 IP (tos 0x0, ttl 64, id 21771, offset 1480, flags [none], proto ESP (50), length 32) 192.168.42.1 > 192.168.42.2: esp

                Goes through:
                13:19:23.807651 IP (tos 0x0, ttl 64, id 49629, offset 0, flags [none], proto ESP (50), length 1496) 192.168.42.1 > 192.168.42.2: ESP(spi=0x045c0bdd,seq=0xb), length 1476

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

                  Perhaps a "esp_frag 552;" in the racoon.conf will help on this issue but I don't know how to add it to that conf file permanent. Every time I reload racoon the line disappears from the conf file.

                  Does anyone know if " esp_frag 552;" will help on this issue?

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

                    Does anyone have any idea on how to fix this issue?

                    1 Reply Last reply Reply Quote 0
                    • P
                      Perry
                      last edited by

                      Could you upgrade to 1.2.3 http://blog.pfsense.org/?p=377

                      /Perry
                      doc.pfsense.org

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

                        Sure. How do I get a hold off it?

                        1 Reply Last reply Reply Quote 0
                        • P
                          Perry
                          last edited by

                          http://snapshots.pfsense.org/FreeBSD7/RELENG_1_2/

                          /Perry
                          doc.pfsense.org

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

                            Upgraded to 1.2.3 with no success. Still the same problem  :-[

                            Can it be a HW failure or HW incompatibility?

                            I've tried a cross-over cable between the two servers with 1000baseTX. I've tried to force the interfaces to 100baseTX with no success and I've tried placing a switch in between. All with the same result.

                            1 Reply Last reply Reply Quote 0
                            • E
                              eri--
                              last edited by

                              did that racoon config helped you ?
                              It seems like pmtu discovery problem. Can you take an tcpdump output file of 1min of traffic and attach here either on the enc0 interface and LAN and wan ones

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

                                I was not able to make the changes to the racoon config. It's overwriten every time racoon starts.

                                I will make a tcpdump asap and attach it here.

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

                                  Here is the dump from the wan interface on pfs1.

                                  I'm not getting any packages on enc0.

                                  I've updated both boxes to 1.2.3 20090224-0050

                                  em1_dump.txt

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

                                    Has anyone any idea?

                                    1 Reply Last reply Reply Quote 0
                                    • P
                                      Perry
                                      last edited by

                                      Commercial support might be the way to go

                                      /Perry
                                      doc.pfsense.org

                                      1 Reply Last reply Reply Quote 0
                                      • E
                                        Eugene
                                        last edited by

                                        Hi Olejak,
                                        have you resolved the problem?
                                        Just interesting…
                                        Actually it is normal for large packets:
                                        13:00:47.407446 IP 192.168.42.2 > 192.168.42.1: ESP(spi=0x01e083a4,seq=0x3), length 1480
                                        13:00:47.407450 IP 192.168.42.2 > 192.168.42.1: esp

                                        I am just wondering whether you receive the same two packets on the other end? I.e. if it is a trace from FW1 do you see the same packets on FW2?

                                        http://ru.doc.pfsense.org

                                        1 Reply Last reply Reply Quote 0
                                        • J
                                          jftuga
                                          last edited by

                                          Try placing a switch between the 2 pfSense servers.  I ran into issues using crossover cables that were cleared up when I used a gig switch instead.

                                          -John

                                          1 Reply Last reply Reply Quote 0
                                          • valnarV
                                            valnar
                                            last edited by

                                            Set the MTU of your adapters down to 1400 and try again.  Large packets + IPSEC + no fragmentation is a common problem.

                                            For Windows, you can use this: http://www.dslreports.com/drtcp

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