VPN IPSEC "ERROR: phase2 negotiation failed due to time up waiting for phase1."

tzerpa

This is the configuration:

Site A pfsense v2.0 beta 5 Feb 18
Site B pfsense v2.0 beta 5 Feb 18
Site C pfsense v2.0 beta 5 Feb 18
Site D pfsense v2.0 beta 5 Feb 18
Site E pfsense v2.0 beta 5 Feb 18

The VPN IPSEC parameters are configuring according to the the how to's

We are using Dyndns:

Site A –-- siteb.dyndns.org
Site B ---- siteb.dyndns.org
Site C ---- sitec.dyndns.org
Site D ---- sited.dyndns.org
Site E ---- sitee.dyndns.org

The local IP address are differents

SITE A 192.168.10.X
SITE B 192.168.11.X
SITE C 192.168.12.X
SITE D 192.168.13.X
SITE E 192.168.14.X

This is the result obtained

VPN IPSEC A --- VPN IPSEC B ---- OK
VPN IPSEC A --- VPN IPSEC C ---- OK
VPN IPSEC A --- VPN IPSEC D ---- "ERROR: phase2 negotiation failed due to time up waiting for phase1."
VPN IPSEC A --- VPN IPSEC E ---- "ERROR: phase2 negotiation failed due to time up waiting for phase1."

There is a sample log

Feb 22 10:00:25 racoon: ERROR: phase1 negotiation failed due to time up. 1d3ba1197c252e5f:0000000000000000
Feb 22 10:00:06 racoon: INFO: delete phase 2 handler.
Feb 22 10:00:06 racoon: [aaa.aaa.aaa.aaa] ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP aaa.aaa.aaa.aaa[0]->bbb.bbb.bbb.bbb[0]
Feb 22 09:59:35 racoon: INFO: begin Aggressive mode.
Feb 22 09:59:35 racoon: [site-C]: INFO: initiate new phase 1 negotiation: bbb.bbb.bbb.bbb[500]<=>aaa.aaa.aaa.aaa[500]
Feb 22 09:59:35 racoon: [site-C]: INFO: IPsec-SA request for aaa.aaa.aaa.aaa queued due to no phase1 found.
–----------------

Any help will be appreciated.

Regards

Tito Zerpa

_igor_

What happens if you disable temporarily the 2 working tunnels? Do the others connect then? I think A initiates the tunnels? What happens if the other sites initiate? Assuming the tunnels are configured right…

tzerpa

I've tested one by one with the same results showed above.

_igor_

then some setting seems to be not synced. Could you post your /var/etc/racoon.conf(s) of the routers? But take out the private parts please.

tzerpa

SITE A

This file is automatically generated. Do not edit

path pre_shared_key "/var/etc/psk.txt";

path certificate "/var/etc";

listen
{
adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
isakmp 111.111.111.111 [500];
isakmp_natt 111.111.111.111 [4500];
}

remote 222.222.222.222
{
ph1id 1;
exchange_mode aggressive;
my_identifier address 111.111.111.111;
peers_identifier address 222.222.222.222;
ike_frag on;
generate_policy = off;
initial_contact = on;
nat_traversal = on;

dpd_delay = 10;
dpd_maxfail = 5;
support_proxy on;
proposal_check claim;

proposal
{
authentication_method pre_shared_key;
encryption_algorithm 3des;
hash_algorithm sha1;
dh_group 2;
lifetime time 28800 secs;
}
}

remote 333.333.333.333
{
ph1id 2;
exchange_mode aggressive;
my_identifier address 111.111.111.111;
peers_identifier address 333.333.333.333;
ike_frag on;
generate_policy = off;
initial_contact = on;
nat_traversal = on;

dpd_delay = 10;
dpd_maxfail = 5;
support_proxy on;
proposal_check claim;

proposal
{
authentication_method pre_shared_key;
encryption_algorithm 3des;
hash_algorithm sha1;
dh_group 2;
lifetime time 28800 secs;
}
}

remote 444.444.444.444
{
ph1id 4;
exchange_mode aggressive;
my_identifier address 111.111.111.111;
peers_identifier address 444.444.444.444;
ike_frag on;
generate_policy = off;
initial_contact = on;
nat_traversal = on;

dpd_delay = 10;
dpd_maxfail = 5;
support_proxy on;
proposal_check claim;

proposal
{
authentication_method pre_shared_key;
encryption_algorithm 3des;
hash_algorithm sha1;
dh_group 2;
lifetime time 28800 secs;
}
}

sainfo subnet 192.168.250.0/24 any subnet 192.168.11.0/24 any
{
remoteid 1;
encryption_algorithm aes 256, aes 192, aes 128, blowfish 256, blowfish 248, blowfish 240, blowfish 232, blowfish 224, blowfish 216, blowfish 208, blowfish 200, blowfish 192, blowfish 184, blowfish 176, blowfish 168, blowfish 160, blowfish 152, blowfish 144, blowfish 136, blowfish 128, 3des, cast128;
authentication_algorithm hmac_sha1,hmac_md5;

lifetime time 3600 secs;
compression_algorithm deflate;
}

sainfo subnet 192.168.250.0/24 any subnet 192.168.12.0/24 any
{
remoteid 2;
encryption_algorithm aes 256, aes 192, aes 128, blowfish 256, blowfish 248, blowfish 240, blowfish 232, blowfish 224, blowfish 216, blowfish 208, blowfish 200, blowfish 192, blowfish 184, blowfish 176, blowfish 168, blowfish 160, blowfish 152, blowfish 144, blowfish 136, blowfish 128, 3des, cast128;
authentication_algorithm hmac_sha1,hmac_md5;

lifetime time 3600 secs;
compression_algorithm deflate;
}

sainfo subnet 192.168.250.0/24 any subnet 192.168.1.0/24 any
{
remoteid 4;
encryption_algorithm aes 256, aes 192, aes 128, blowfish 256, blowfish 248, blowfish 240, blowfish 232, blowfish 224, blowfish 216, blowfish 208, blowfish 200, blowfish 192, blowfish 184, blowfish 176, blowfish 168, blowfish 160, blowfish 152, blowfish 144, blowfish 136, blowfish 128, 3des, cast128;
authentication_algorithm hmac_sha1,hmac_md5;

lifetime time 3600 secs;
compression_algorithm deflate;
}
–---------------------------------------------------------------------------------------------------------------------

SITE B

This file is automatically generated. Do not edit

path pre_shared_key "/var/etc/psk.txt";

path certificate "/var/etc";

listen
{
adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
isakmp 222.222.222.222 [500];
isakmp_natt 222.222.222.222 [4500];
}

remote 111.111.111.111
{
ph1id 1;
exchange_mode aggressive;
my_identifier address 222.222.222.222;
peers_identifier address 111.111.111.111;
ike_frag on;
generate_policy = off;
initial_contact = on;
nat_traversal = on;

dpd_delay = 10;
dpd_maxfail = 5;
support_proxy on;
proposal_check claim;

proposal
{
authentication_method pre_shared_key;
encryption_algorithm 3des;
hash_algorithm sha1;
dh_group 2;
lifetime time 28800 secs;
}
}

sainfo subnet 192.168.11.0/24 any subnet 192.168.250.0/24 any
{
remoteid 1;
encryption_algorithm aes 256, aes 192, aes 128, blowfish 256, blowfish 248, blowfish 240, blowfish 232, blowfish 224, blowfish 216, blowfish 208, blowfish 200, blowfish 192, blowfish 184, blowfish 176, blowfish 168, blowfish 160, blowfish 152, blowfish 144, blowfish 136, blowfish 128, 3des, cast128;
authentication_algorithm hmac_sha1,hmac_md5;

lifetime time 3600 secs;
compression_algorithm deflate;
}

–--------------------------------------------------------------------------------------------------------------------------

SITE E

This file is automatically generated. Do not edit

path pre_shared_key "/var/etc/psk.txt";

path certificate "/var/etc";

listen
{
adminsock "/var/db/racoon/racoon.sock" "root" "wheel" 0660;
isakmp 444.444.444.444 [500];
isakmp_natt 444.444.444.444 [4500];
}

remote 111.111.111.111
{
ph1id 1;
exchange_mode aggressive;
my_identifier address 444.444.444.444;
peers_identifier address 111.111.111.111;
ike_frag on;
generate_policy = off;
initial_contact = on;
nat_traversal = on;

dpd_delay = 10;
dpd_maxfail = 5;
support_proxy on;
proposal_check claim;

proposal
{
authentication_method pre_shared_key;
encryption_algorithm 3des;
hash_algorithm sha1;
dh_group 2;
lifetime time 28800 secs;
}
}

sainfo subnet 192.168.1.0/24 any subnet 192.168.250.0/24 any
{
remoteid 1;
encryption_algorithm aes 256, aes 192, aes 128, blowfish 256, blowfish 248, blowfish 240, blowfish 232, blowfish 224, blowfish 216, blowfish 208, blowfish 200, blowfish 192, blowfish 184, blowfish 176, blowfish 168, blowfish 160, blowfish 152, blowfish 144, blowfish 136, blowfish 128, 3des, cast128;
authentication_algorithm hmac_sha1,hmac_md5;

lifetime time 3600 secs;
compression_algorithm deflate;
}

_igor_

Is there any reason to enable all algorithms? You control the tunnels at all sites, so elect one algo and disable the others.

In your first question you said that the nets are .11.0/24, .12.0/24 and so on. Your Site E shows .1.0/24. Site D is not included, so maybe here is your mistake? Wrong net?

tzerpa

Hi Igor,

I've made a lot of test using one by one of the algorithms on each site. The mainly reason to enable all algorithms was back to the initial standard configuration.

Site E was change from 14.x to 1.x just for testing.

Site D was not included because at this moment the router is off.

If you want to check by yourself please email me at tzerpa@infor.com.ve

Regards,

Tito

databeestje

Please check your lifetimes, ipsec-tools 0.8 is a lot stricter about those.

I've had a number of tunnels failing to come up because the phase 1 lifetime was 3600 on one end and 28800 on the other. After matching those up it worked.

blacklotus

i am having the same exact problem!

i am using the latest x64 build (02/24/2011) and i actually have a mix of main and aggressive tunnels because some are static ip's and some are dynamic.

my pfsense is on statis ip's and was R1.2.3 with 6 remote sites connected using IPSEC. all the remote sites are using Linksys RV802/402 routers.
i have 2 main subnets at my main site
all the the Linksys routers only really support one apeice so we had to setup 2 tunnels on each router connecting to pfsense one for LAN & one for VOIP.

Here's the setup:
Main Site pfSense 2.0-BETA5 (amd64) built on Thu Feb 24 18:23:48 EST 2011
On an intel PT1000 dual LAN nic setup for 802.3ad (LACP) LAG (em0 + em1):
LAN (192.168.10.0/24) VLAN10 (lan interface)
VOIP (172.16.10.0/24) VLAN500 (opt9 interface)
other irrelevant & test vlans on the same LAG
The WAN links are setup on a third intel interface em2
WAN1 = T1 (VLAN4001) IPSEC tunnels connect to this
WAN2-4 = (VLAN4002-4004) Gateway group for internet traffic
pfsync (10.254.254.0/24) on dedicated interface re0
i have carp interfaces setup per the tutorial and everything appears to be working
the second pfsense firewall has not yet been added (but will be)

so the Remote sites are:
Linksys/Cisco RV802
192.168.100.0/24 | tunnel1 => 192.168.10.0/24 | tunnel2 => 172.16.10.0/24
Linksys/Cisco RV402
192.168.101.0/24 | tunnel1 => 192.168.10.0/24 | tunnel2 => 172.16.10.0/24
Linksys/Cisco RV402
192.168.102.0/24 | tunnel1 => 192.168.10.0/24 | tunnel2 => 172.16.10.0/24
Linksys/Cisco RV402
192.168.103.0/24 | tunnel1 => 192.168.10.0/24 | tunnel2 => 172.16.10.0/24
Linksys/Cisco RV402
192.168.104.0/24 | tunnel1 => 192.168.10.0/24 | tunnel2 => 172.16.10.0/24
Linksys/Cisco RV402
192.168.105.0/24 | tunnel1 => 192.168.10.0/24 | tunnel2 => 172.16.10.0/24

On pfsense 1.2.3 i had to setup 2 tunnels per site and all was working well

decided to "upgrade" to 2.0 (i know not production so thats why we're testing). main things we wanted to do was carp redundancy (for 2 pfsense firewalls) along with LAG (lacp).

had to setup the IPsec differently, because of multiple phase2's to each phase 1 (i LOVE that btw) and 2.0 won't let me setup more than 1 phase1 per remote endpoint. had to setup the endpoint IP to the CARP address (of course).
now the wierd thing is that some tunnels come up fine AND if a site comes up, BOTH Phase 2's come up fine. No rhyme of reason either because some of the working ones are MAIN and some are AGGRESSIVE.

I'm thinking its could be the multi phase 2's that are screwing things up since the Linksys RV's don't support multiple phase2's per phase1. SO i took one of the problem sites and WIPED the phase one from BOTH the pfsense and the Linksys and created a new phase1 with only a single phase2 and only ONE tunnel on the Linksys.

i noticed some phase1 PSK errors in the VPNlog so i created some Pre-shared keys the old way in the preshared key tab. interesting thing is that without ANY keys in the preshared key tab i had 8 tunnels UP AND RUNNING.

Still doesn't come up and is giving several messages in the log
NOTIFY: the packet is retransmitted by {REMOTEIP}[500] (1).
racoon: ERROR: phase1 negotiation failed due to time up. 15be5a31877243b6:60dcd2d5d19df3ea
racoon: [REMOTEIP] ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP {REMOTEIP}[0]->{LOCALIP}[0]

wierd thing is that i check the logs on the remote routers that are failing and i get:
Feb 26 10:35:10 2011 VPN Log Initiating Main Mode
Feb 26 10:35:10 2011 VPN Log [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Feb 26 10:35:10 2011 VPN Log [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Feb 26 10:48:19 2011 VPN Log Initiating Main Mode to replace #978
Feb 26 10:48:19 2011 VPN Log [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Feb 26 11:01:29 2011 VPN Log Initiating Main Mode to replace #979
Feb 26 11:01:29 2011 VPN Log [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet
Feb 26 11:01:29 2011 VPN Log [Tunnel Negotiation Info] >>> Initiator Send Main Mode 1st packet

the failing tunnels never seem to get a response from pfsense.

i had 8 of 12 tunnels working at one point in time which seemed pretty good although i couldn't get the last 2 sites up. the wierd thing is that the 2 problem site were static IP's with main mode tunnels! i tried restarting the remote routers and that didn't resolve anything. so instead i decide to restart pfsense and now only 4 tunnels come up! TWO are to a static ip and 2 are to a dynamic IP.

there appears to be no rhyme or reason as to why some tunnels work and some don't. the other thing that puzzles me is that the failing VPN remote endpoints don't receive ANY response from pfsense. there isn't even any consistency between the ones that fail as well as the types of ones that fail.
keep in mind this setup was working fine with pfsense 1.2.3

tzerpa

databeestje

the lifetime in phase 1 is 28800 and the lifetime in phase to is 3600 an they are exactly the same in all routers

tzerpa

All the routers updated to 2.0 RC1 Feb 28 and the problem continue ….

tzerpa

All the routers updated to 2.0 RC1 March 3 and the problem continue ….

databeestje

You will have to check the settings, All my tunnels work. The few that did not after the upgrade were caused by subtle mismatches.

tzerpa

I've double checked the setting many times also I've deleted the vpn and check one by one with the same results.

The next step is to check the network cards finding some kind of driver issue.

I can send in a private message the ip address and user/password If someone want to help me.

Thanks again,

Tito

tzerpa

The things are getting worse

Now after the last release (2.0-RC1 (i386) built on Mon Mar 14 21:14:15 EDT 2011) we can´t connect with any of the VPN sites.

eri--

You are sure there is no firewall rule preventing this?

rlai000

Are you suffering the same symptom as mine (http://forum.pfsense.org/index.php/topic,33892.0.html) because I see you're using FQDN as the remote gateway.

-Raylund

tzerpa

ermal: I check the firewall rules and now I'm back to the initial stage of this post two VPNs "connected" and the rest of VPNs "not connected" with the same information as above

raylund: I replace the FQDN with the IPs and same result two VPNs "connected" and the rest of VPNs "not connected"

rlai000

May be you check the MTU between the sites. -Raylund

tzerpa

Hi Raylund,

I will check your recommendations but I think something is happen and no one are interested to check or help in depth to solve it.

I've experience since 1994 installing and configuring routers and I've found pfSense as and extraordinary solution but in my opinion the RC1 looks like a beta instead of a Release Candidate.

:(

Tito