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]
