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

    IPSec pfsense <-> Fritzbox broken in 2.2

    Scheduled Pinned Locked Moved
    IPsec
    10
    20
    10.4k
    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.
    • C
      crazynet24
      last edited by

      Same here:
      The tunnel between Fritzbox (v06.21) and the new pfsense version 2.2 is broken. The error code in the fritzbox is 2020 ("hash mismatch in received packet").

      I guess, that's the corresponding log in the pfsense:
      charon: 16[ENC] generating INFORMATIONAL_V1 request 2386031426 [ HASH N(AUTH_FAILED) ]
      charon: 16[IKE] calculated HASH does not match HASH payload
      charon: 16[IKE] <con1000|1993>calculated HASH does not match HASH payload

      At least, I'm also missing parameters for "proposal generation" and "proposal checking" in the new version. (like shown here: http://znil.net/index.php?title=FritzBox_-_Site_to_Site_VPN_zu_pfSense_2.1.5)

      Another issue is, that I've never needed Firewall rules at the WAN-IF for port 500, 4500 and ESP in version 2.1.5. Obviously that has changed in 2.2, I need the rules now (good!).

      Nevertheless, I will switch back to 2.1.5 this night, because I see no way to get the IPSec tunnel work. I don't wan't to waste days in debugging this feature, though it has worked stable bevor.

      greetings</con1000|1993>

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

        This error seems to be back in 2.2.3  :(

        but only some connections are affected.

        7490 connects fine via AES (FW 6.24)
        7362SL does not connect via AES / 3DES (FW 6.20)

        other models also do not connect. (FW 6.22)

        Are there any hints or fixes by someone ?
        Disabling AESNI does not fix anything.

        pfSense 2.2.4-DEVELOPMENT (amd64) built on Mon Jun 29 14:25:17 CDT 2015 does not fix this so far.

        1 Reply Last reply Reply Quote 0
        • C
          cmb
          last edited by

          Are you getting "auth failed" as in the original log?

          1 Reply Last reply Reply Quote 0
          • M
            methyphobia
            last edited by

            I can confirm trendchiller observations, 2.2.3 broke my tunnel to a Fritzbox as well.

            pfSense-Log:

            Jul  1 10:35:55 filter charon: 12[KNL] creating acquire job for policy 212.x.x.x/32|/0 === 91.x.x.x/32|/0 with reqid {5}
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>initiating Aggressive Mode IKE_SA con1000[839] to 91.x.x.x
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>initiating Aggressive Mode IKE_SA con1000[839] to 91.x.x.x
            Jul  1 10:35:55 filter charon: 11[ENC] <con1000|839>generating AGGRESSIVE request 0 [ SA KE No ID V V V V V V ]
            Jul  1 10:35:55 filter charon: 11[NET] <con1000|839>sending packet: from 212.x.x.x[500] to 91.x.x.x[500] (344 bytes)
            Jul  1 10:35:55 filter charon: 11[NET] <con1000|839>received packet: from 91.x.x.x[500] to 212.x.x.x[500] (328 bytes)
            Jul  1 10:35:55 filter charon: 11[ENC] <con1000|839>parsed AGGRESSIVE response 0 [ SA KE No ID HASH N((24576)) V V ]
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>received XAuth vendor ID
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>received XAuth vendor ID
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>received DPD vendor ID
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>received DPD vendor ID
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>calculated HASH does not match HASH payload
            Jul  1 10:35:55 filter charon: 11[IKE] <con1000|839>calculated HASH does not match HASH payload
            Jul  1 10:35:55 filter charon: 11[ENC] <con1000|839>generating INFORMATIONAL_V1 request 4262830151 [ HASH N(AUTH_FAILED) ]
            Jul  1 10:35:55 filter charon: 11[NET] <con1000|839>sending packet: from 212.x.x.x[500] to 91.x.x.x[500] (84 bytes)

            Fritzbox logs either Error 0x2020 (hash mismatch in received packet) or 0x2027 (timeout)</con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839></con1000|839>

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              What phase 1 identifiers are you using?

              1 Reply Last reply Reply Quote 0
              • M
                methyphobia
                last edited by

                @cmb:

                What phase 1 identifiers are you using?

                On my (pfsense) site the identifier is my public IP address (which is static). The Fritzbox has a dynamic IP, I'm using a dynamic DNS name as it's identifier.
                The settings match on both sides and the tunnel worked flawlessly on 2.2.2 (as well as 2.2.1).

                1 Reply Last reply Reply Quote 0
                • C
                  cmb
                  last edited by

                  Someone who has one, could you get me into your system to review? PM me to arrange details.

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

                    Hi Chris !
                    We are using distinguished names as authenticator using a dns-name for both sides.

                    Phase 1:
                    Key-Exchange: V1
                    IPv4
                    Mutual-PSK
                    aggressive-mode

                    3DES, SHA1, DH1, 3600 sec lifetime

                    Phase 2:
                    Tunnel IPv4
                    ESP
                    3DES, SHA1, PFS 1, 3600 sec lifetime

                    the logs show:
                    Jul 3 14:48:31 charon: 11[ENC] <con7000|29>generating INFORMATIONAL_V1 request 1702398447 [ HASH N(AUTH_FAILED) ]
                    Jul 3 14:48:31 charon: 11[IKE] <con7000|29>calculated HASH does not match HASH payload
                    Jul 3 14:48:31 charon: 11[IKE] <con7000|29>calculated HASH does not match HASH payload</con7000|29></con7000|29></con7000|29>

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      This has been confirmed fixed in 2.2.4 snapshots by someone who has a Fritzbox remote endpoint. Replacing /etc/inc/vpn.inc, or upgrading to latest 2.2.4 from https://snapshots.pfsense.org will fix.

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

                        I cannot confirm :-(
                        anyone else with thesame persisting problems ?

                        1 Reply Last reply Reply Quote 0
                        • F
                          feydin
                          last edited by

                          Replacing the vpn.inc from Github and restarting IPSec indeed fixed the issue for me. Thanks.

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

                            @trendchiller:

                            I cannot confirm :-(
                            anyone else with thesame persisting problems ?

                            For me the problem also persists:

                            Fritzbox 7270 with FRITZ!OS 06.05 <-> 2.2.4-RELEASE (i386) built on Sat Jul 25 19:56:41 CDT 2015

                            Fritz-Log:
                            18.08.15 16:03:20 VPN-Fehler: company_vpn, IKE-Error 0x203f

                            PF-Sense-Log:
                            Aug 18 16:12:42 charon: 09[NET] <con2000|466>sending packet: from xx.xx.xx.xx[500] to xx.xx.xx.xx[500] (84 bytes)
                            Aug 18 16:12:42 charon: 09[ENC] <con2000|466>generating INFORMATIONAL_V1 request 1247132810 [ HASH N(AUTH_FAILED) ]
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>calculated HASH does not match HASH payload
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>calculated HASH does not match HASH payload
                            Aug 18 16:12:42 charon: 09[ENC] <con2000|466>received unknown vendor ID: a2:22:6f:c3:64:50:0f:56:34:ff:77:db:3b:74:f4:1b
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received draft-ietf-ipsec-nat-t-ike-03 vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received draft-ietf-ipsec-nat-t-ike-03 vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received NAT-T (RFC 3947) vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received NAT-T (RFC 3947) vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received DPD vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received DPD vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received XAuth vendor ID
                            Aug 18 16:12:42 charon: 09[IKE] <con2000|466>received XAuth vendor ID
                            Aug 18 16:12:42 charon: 09[ENC] <con2000|466>parsed AGGRESSIVE response 0 [ SA KE No ID HASH N((24576)) V V V V V NAT-D NAT-D ]

                            Any help would be greatly appreciated!

                            Thanks
                            Florian</con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466></con2000|466>

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

                              Same for me, FB 7390 FritzOS 6.30 <> pfSense 2.2.4-RELEASE (i386)

                              Did work with previous versions, iirc with 2.1.x, but seems to be broken since 2.2.

                              Hope someone can help!?

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

                                We seem to have the same problem here after upgrading to 2.2.4 when connecting to a cisco firewall.
                                Log (descending):

                                charon: 07[NET] <con4000|103>sending packet: from xxx.xxx.xxx.xxx[500] to yyy.yyy.yyy.yyy[500] (92 bytes)
                                charon: 07[ENC] <con4000|103>generating INFORMATIONAL_V1 request 2671423441 [ HASH N(AUTH_FAILED) ]
                                charon: 07[IKE] <con4000|103>calculated HASH does not match HASH payload
                                charon: 07[IKE] <con4000|103>calculated HASH does not match HASH payload
                                charon: 07[ENC] <con4000|103>received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00

                                Configuration:
                                Key Exchange Version: 1
                                IPv4
                                Authentication method: Mutual PSK
                                Negotiation mode: Aggressive

                                regards,

                                eCat</con4000|103></con4000|103></con4000|103></con4000|103></con4000|103>

                                1 Reply Last reply Reply Quote 0
                                • ?
                                  Guest
                                  last edited by

                                  @eCat
                                  Try upgrade to pfSense version 2.2.5 and try it out once more again.

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

                                    Thanks for the answer, BlueKobold.
                                    Guess i'll have to wait for the stable then since we're using the firewall in production environment.

                                    greetings (from germany too  ;))

                                    1 Reply Last reply Reply Quote 0
                                    • C
                                      cmb
                                      last edited by

                                      @eCat:

                                      We seem to have the same problem here after upgrading to 2.2.4 when connecting to a cisco firewall.

                                      That's not the same problem, and upgrading to 2.2.5 won't change that. It's likely one of the changes noted here:
                                      https://doc.pfsense.org/index.php/UpgradeGuide#IPsec_Changes

                                      either "Stricter Phase 1 Identifier Validation" or "Phase 2 behavior change with incorrect network addresses" most likely.

                                      Start a new thread describing your issue if neither of those appear to be the case.

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

                                        Small Update on the (cisco) issue:
                                        The tunnel works again. We tried several configurations - using the remote hostname (IP did NOT work) as remote gateway and Peer Identifier 'any' finally did the trick.
                                        (Doesn't make much sense for me - however: it works ;))

                                        regards,

                                        eCat

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          rtv
                                          last edited by

                                          I get this message daily when pfsense fails to reconnect my IPSec tunnel to the Fritz!Box (7390).
                                          It worked nicely until 2.2.2 in aggressive mode. Now that other bugs are fixed I could finally upgrade to 2.2.6 and switch to main mode.

                                          The initial connection comes up fine. Just after the 24h disconnect the tunnel will not be reestablished and I get the same log entries.

                                          Confusing but maybe helpful: If I use another IPSec connection from my Smartphone (with VPNCilla, inside LAN) to the Fritz!Box then the pfsense tunnel comes up simultaneously  :o

                                          1 Reply Last reply Reply Quote 0
                                          • ?
                                            Guest
                                            last edited by

                                            The initial connection comes up fine. Just after the 24h disconnect the tunnel will not be reestablished and I get the same log entries.

                                            It seems the ISP cut the line all 24h once, like here in Germany and the IPSec connection is not coming
                                            up proper again.

                                            Confusing but maybe helpful: If I use another IPSec connection from my Smartphone (with VPNCilla, inside LAN) to the Fritz!Box then the pfsense tunnel comes up simultaneously  :o

                                            If there will be then a packet flow through the tunnel it will be perhaps revive the older IPSec VPN tunnel
                                            also again and its up then. Did you try out to get from your PC a link or data flow through the tunnel
                                            by opening the briwser and start connecting some devices on the other side of the VOPN tunnel, or perhaps
                                            another program running on a device in the LAN?

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