Holy crap Batman! This might have fixed it. Did a little bit of testing only with the pix as the remote client it comes up after simulated power outages and builds the tunnel again without issue. Tested with long/short SA see how it reacts if SAs are expired and it still comes up. It actually seems pretty stable actually and pretty tough to make the tunnel fail now.
Will continue doing some testing to confirm. Thanks for the tip! John -----Original Message----- From: Bill Marquette [mailto:[EMAIL PROTECTED] Sent: Sunday, February 19, 2006 10:03 PM To: support@pfsense.com Subject: Re: [pfSense Support] IPSec Testing Not sure if you've tried this, if it'll make a difference, or what exactly it'll do, but try "Prefer old IPsec SAs" in System->Advanced I'm having no problems with my tunnels, pfsense-pfsense and pfsense-nortel contivity, but they're both network tunnel configs with static IPs, not road warrior. --Bill On 2/19/06, John Cianfarani <[EMAIL PROTECTED]> wrote: > > > > Been doing some testing the last little bit to try to nail down what it > isn't working right with IPSec tunnels and I just wanted to give an update > and maybe get some suggestions on what to try next. > > > > I've moved one of the pfsense boxes (running Beta1 Snapshot 2-2-06) into a > colo location to confirm that the internet was not the issue. > > The Colo pfsense is setup for mobile clients and I have 2 boxes (at 2 > different locations) acting as remote client. > > > > One of the clients is another pfsense box running Beta1 and the other is a > Cisco Pix. > > > > Both boxes connect and establish their tunnels (and renegotiate as lifetimes > expires tested over 2-3 days) though after a simulated power outage with the > Cisco Pix it is never able to reconnect after that point. > > The next day the remote pfsense then no longer is able to connect. Trying to > disable/enable ipsec on the colo pfsense seems to have no limited to no > effect. (sometimes it works sometimes it doesn't) > > > > Both remote boxes seem to complain about retransmitting of phase 1 so it > doesn't even seem like IKE listening anymore, even though a netstat shows > it's running. The colo pfsense also doesn't show any log entries while the > box is retrying (even with the extended debug on for raccoon). > > > > My thought at the moment is that somehow the colo pfsense doesn't think the > tunnel has ever gone down and maybe treats the new isakmp requests > differently. > > > > This is what I'm thinking for next tests: > > 1. My thoughts for the next tests are to try to use the pix as the central > site and to try to get pfsense to connect into it. > > 2. Other though is to go back and try 94.x 95.x with ipsec-tools 6.2 to see > if I can replicate it there. > > 3. Try to use the developer ed. and build with ipsec-tools 6.2 > > > > > > Thanks > > John > > > > Here are some logs as well. > > > > z.z.z.z is colo pfsense > > a.a.a.a is remote pfsense > > b.b.b.b is cisco pix > > > > -- Colo Pfsense - netstat -- > > Active Internet connections > > Proto Recv-Q Send-Q Local Address Foreign Address (state) > > udp4 0 0 gw-central2.isakmp *.* > > udp4 0 0 192.168.1.2.isakmp *.* > > udp4 0 0 z.z.z.z.isakmp *.* > > udp4 0 0 localhost.isakmp *.* > > > > > > -- remote pfsense - ipsec log --- > > Feb 19 20:58:00 racoon: INFO: initiate new phase 1 negotiation: > a.a.a.a[500]<=>z.z.z.z[500] > > Feb 19 20:58:00 racoon: INFO: begin Aggressive mode. > > Feb 19 20:58:31 racoon: ERROR: phase2 negotiation failed due to > time up waiting for phase1. ESP z.z.z.z[0]->a.a.a.a[0] > > Feb 19 20:58:31 racoon: INFO: delete phase 2 handler. > > Feb 19 20:59:00 racoon: INFO: request for establishing IPsec-SA > was queued due to no phase1 found. > > > > > > --- remote cisco pix debug -- > > > > ISAKMP (0): ID payload > > next-payload : 13 > > type : 11 > > protocol : 17 > > port : 500 > > length : 28 > > ISAKMP (0): Total payload length: 32 > > ISAKMP (0): beginning Aggressive Mode exchange > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): retransmitting phase 1... > > ISAKMP (0): deleting SA: src b.b.b.b, dst z.z.z.z > > ISADB: reaper checking SA 0x9e66ec, conn_id = 0 DELETE IT! > > > > VPN Peer:ISAKMP: Peer Info for z.z.z.z/500 not found - peers:0 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]