IPSec pfsense <-> Fritzbox broken in 2.2
-
What phase 1 identifiers are you using?
-
@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). -
Someone who has one, could you get me into your system to review? PM me to arrange details.
-
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-mode3DES, SHA1, DH1, 3600 sec lifetime
Phase 2:
Tunnel IPv4
ESP
3DES, SHA1, PFS 1, 3600 sec lifetimethe 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> -
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.
-
I cannot confirm :-(
anyone else with thesame persisting problems ? -
Replacing the vpn.inc from Github and restarting IPSec indeed fixed the issue for me. Thanks.
-
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 0x203fPF-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> -
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!?
-
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:00Configuration:
Key Exchange Version: 1
IPv4
Authentication method: Mutual PSK
Negotiation mode: Aggressiveregards,
eCat</con4000|103></con4000|103></con4000|103></con4000|103></con4000|103>
-
@eCat
Try upgrade to pfSense version 2.2.5 and try it out once more again. -
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 ;))
-
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_Changeseither "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.
-
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
-
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
-
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?