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]

Reply via email to