ERROR: phase 1 negotiation failed due to time up



  • Hi!,
      I used to have a pfSense connected through IPSEC to a Smoothwall Advanced Firewall. It worked excellent for a month, but yesterday the vpn failed. My ISP had a problem with one of their switches, they changed the switch anda said things should work now, but my vpn doesn't get up.

    I keep getting this on the log:

    Jun 13 12:06:46 racoon: ERROR: phase1 negotiation failed due to time up. 4baa73eefc113f32:269150198cb6b0cb
    Jun 13 12:06:37 racoon: [UnimarNic]: NOTIFY: the packet is retransmitted by 1.1.1.1[500].
    Jun 13 12:05:56 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
    Jun 13 12:05:56 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
    Jun 13 12:05:56 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
    Jun 13 12:05:56 racoon: INFO: received Vendor ID: RFC 3947
    Jun 13 12:05:56 racoon: INFO: received Vendor ID: DPD
    Jun 13 12:05:56 racoon: INFO: begin Identity Protection mode.
    Jun 13 12:05:56 racoon: [UnimarNic]: INFO: respond new phase 1 negotiation: 2.2.2.2[500]<=>1.1.1.1[500]

    Where:
      1.1.1.1 is the public ip of the smoothwall firewall.
      2.2.2.2 is the public ip of my pfsense.

    any advice would be appreciated,
    thanks in advance.


  • Rebel Alliance Developer Netgate

    Have you tried just restarting racoon on the pfSense box, or perhaps running setkey -F from Diagnostics > Command?

    Not sure if you may also have to do something similar on Smoothwall.

    Unfortunately, many versions of ipsec-tools do not properly handle tunnels that timeout due to connectivity loss, an issue we're working hard to fix before 1.2.3 is released, but this is not a problem unique to pfSense, since it is a problem in ipsec-tools itself.

    As a last resort, you could try rebooting both boxes, but that is a little severe for something that should be fixable by restarting the racoon daemon (hopefully).



  • @jimp:

    Have you tried just restarting racoon on the pfSense box, or perhaps running setkey -F from Diagnostics > Command?

    Already did both things, nothing changed…

    what does setkey -F ? log didn't show anything when I executed it... :-\

    @jimp:

    As a last resort, you could try rebooting both boxes, but that is a little severe for something that should be fixable by restarting the racoon daemon (hopefully).

    Also did reboot both boxes, I even made new brand VPN….same message keeps showing. I was wondering if maybe it would be something on the side of my ISP that's no allowing me to bring the VPN up....?

    I have another pfsense's VPN with same settings on another completely different remote site...and it's working ok...

    any other advice?


  • Rebel Alliance Developer Netgate

    @esanchez:

    Already did both things, nothing changed…

    what does setkey -F ? log didn't show anything when I executed it... :-\

    It flushes the SAD entries, which can bring a stuck tunnel back to life sometimes by forcing it to reconnect.

    Also did reboot both boxes, I even made new brand VPN….same message keeps showing. I was wondering if maybe it would be something on the side of my ISP that's no allowing me to bring the VPN up....?

    That is possible, but unlikely. Considering they changed out a piece of equipment it may be more likely than it would be otherwise… not sure exactly how that would have affected your VPN tunnel specifically, but it's possible.

    I have another pfsense's VPN with same settings on another completely different remote site…and it's working ok...

    any other advice?

    If both tunnels are configured similarly on your side, and one works and the other doesn't, I'd be more suspicious of the far end or things in between.

    It may help to post the full (sanitized if you like) IPsec logs from the pfSense side and maybe even the Smoothwall side just to see if they may hold any more clues.



  • well, just was reviewing the smoothwall logs, and I found this:

    16:26:08  Unimar_Nicaragua  starting keying attempt 28 of an unlimited number
    16:26:08 Unimar_Nicaragua initiating Main Mode to replace #389
    16:39:18 Unimar_Nicaragua max number of retransmissions (20) reached STATE_MAIN_I1. No response (or no acceptable response) to our first IKE message



  • Well, after pulling my hair out of my head  ???, we decided to use another public address, and then… it worked...
    thanks everyone for their valuable help! :)

    best regards!


Log in to reply