Pfsense 2.2.4 ipsec to pfsense 2.1.5 all tunnel down after 2.2.3 to 2.2.4



  • We have 20 or so remote pfsense firewalls at sites.  All currently running pfsense 2.2.3 and estabishing several phase 2 tunnels to a primary pfsense firewall at our main site running pfsense 2.1.5.

    Yesterday I upgraded a pfsense 2.3.3 remote firewall to 2.2.4.

    After this the 2.2.4 remote firewall is still pingable via the wan ip.  However the tunnels are all down now and rebooting the firewall has not repaired the connection.

    Will update as I work on the issue.



  • [2.1.5-RELEASE][admin@fw01.fake.domain]/var/log(7): cat ipsec.log | grep x.x.x.x
    Jul 29 12:37:42 fw01 racoon: [x.x.x.x] ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP x.x.x.x[0]->216.12.35.54[0]
    Jul 29 12:37:45 fw01 racoon: [x.x.x.x] ERROR: invalid flag 0x08.
    Jul 29 12:39:01 fw01 racoon: [x.x.x.x] ERROR: invalid flag 0x08.
    Jul 29 12:39:05 fw01 racoon: [x.x.x.x] ERROR: invalid flag 0x08.
    Jul 29 12:39:12 fw01 racoon: [x.x.x.x] ERROR: invalid flag 0x08.
    Jul 29 12:39:25 fw01 racoon: [x.x.x.x] ERROR: invalid flag 0x08.
    Jul 29 12:37:11 fw01 racoon: INFO: IPsec-SA request for x.x.x.x queued due to no phase1 found.
    Jul 29 12:37:11 fw01 racoon: INFO: initiate new phase 1 negotiation: y.y.y.y[500]<=>x.x.x.x[500]
    Jul 29 12:37:11 fw01 racoon: [x.x.x.x] INFO: Selected NAT-T version: RFC 3947
    Jul 29 12:37:11 fw01 racoon: [x.x.x.x] INFO: Hashing x.x.x.x[500] with algo #4
    Jul 29 12:37:11 fw01 racoon: [x.x.x.x] INFO: Hashing x.x.x.x[500] with algo #4
    Jul 29 12:37:18 fw01 racoon: [x.x.x.x] ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP x.x.x.x[0]->y.y.y.y[0]

    Event Log: "invalid flag 0x08"

    Error Description: The MX only supports site-to-site VPN using IKEv1. If IKEv2 is configured on the remote end, the message "invalid flag 0x08" may be seen in the event log.

    Error Solution: Switch the remote end from using IKE v2 to v1.

    So pfsense 2.2.4 forces ike v2 after upgrade I belive it was set to auto for phase 1 configuration on the remote side?  I will try to force ike v1 on the remote firewall and see what happens then report back here…



  • "auto" mode was converted to IKEv2 on upgrade, as only IKEv2 would have worked 100% correctly with auto mode as things stood. It would have used IKEv2 as initiator before the upgrade, and hence been broken in that direction, you just didn't notice, or happened to have the other end as initiator by chance on every attempt.

    Need to change it to IKEv1 to match what your other end is, and should have had it that way prior to the upgrade.



  • It is working now that I've set it to IKEv1.  Thank you for the explanation.