Thanks Chris for the quick reply, I am using NAT-T option for this IPsec Tunnel, forgot to mention that, is that another way to resolve it?
Thanks On Sun, Jan 15, 2012 at 2:39 AM, Chris Buechler <[email protected]> wrote: > On Sat, Jan 14, 2012 at 8:26 PM, Aymen Belkhiria > <[email protected]> wrote: > > > > I am using pfsense 2 and I have many drops on my IPsec Tunnel, here the > log: > > > > Jan 14 20:03:54 racoon: [NAT Test]: INFO: ISAKMP-SA established > > xx.xx.xx.xx[4500]-xx.xx.xx.xx[4500] spi:ef320f25a6ad35e8:0f6e6a71aa89b928 > > Jan 14 20:03:54 racoon: [NAT Test]: INFO: KA found: > > xx.xx.xx.xx[4500]->xx.xx.xx.xx[4500] (in_use=2) > > Jan 14 20:03:54 racoon: [NAT Test]: INFO: NAT-T: ports changed to: > > xx.xx.xx.xx[4500]<->xx.xx.xx.xx[4500] > > Jan 14 20:03:54 racoon: INFO: Adding remote and local NAT-D > payloads. > > Jan 14 20:03:54 racoon: [Self]: [xx.xx.xx.xx] INFO: Hashing > > xx.xx.xx.xx[500] with algo #2 > > Jan 14 20:03:54 racoon: [NAT Test]: [xx.xx.xx.xx] INFO: Hashing > > xx.xx.xx.xx[500] with algo #2 > > Jan 14 20:03:54 racoon: INFO: NAT detected: ME PEER > > Jan 14 20:03:54 racoon: INFO: NAT-D payload #1 doesn't match > > Jan 14 20:03:54 racoon: [NAT Test]: [xx.xx.xx.xx] INFO: Hashing > > xx.xx.xx.xx[500] with algo #2 > > Jan 14 20:03:54 racoon: INFO: NAT-D payload #0 doesn't match > > Jan 14 20:03:54 racoon: [Self]: [xx.xx.xx.xx] INFO: > Hashing xx.xx.xx.xx > > [500] with algo #2 > > > > Jan 14 20:03:54 racoon: [NAT Test]: [xx.xx.xx.xx] INFO: Selected > NAT-T > > version: RFC 3947 > > > > Jan 14 20:03:54 racoon: INFO: received Vendor ID: > > draft-ietf-ipsec-nat-t-ike-00 > > Jan 14 20:03:54 racoon: INFO: received Vendor ID: > > draft-ietf-ipsec-nat-t-ike-02 > > Jan 14 20:03:54 racoon: INFO: received Vendor ID: > > draft-ietf-ipsec-nat-t-ike-02 > > Jan 14 20:03:54 racoon: INFO: received Vendor ID: > > draft-ietf-ipsec-nat-t-ike-03 > > Jan 14 20:03:54 racoon: INFO: received Vendor ID: RFC 3947 > > Jan 14 20:03:54 racoon: INFO: received Vendor ID: DPD > > Jan 14 20:03:54 racoon: INFO: begin Identity Protection mode. > > Jan 14 20:03:54 racoon: [NAT Test]: INFO: respond new phase 1 > negotiation: > > xx.xx.xx.xx[500]<=>xx.xx.xx.xx[500] > > Jan 14 20:03:31 racoon: [NAT Test]: INFO: renegotiating phase1 to > > xx.xx.xx.xx due to active phase2 > > > > Jan 14 19:58:03 racoon: [NAT Test]: INFO: IPsec-SA established: ESP > > xx.xx.xx.xx[500]->184.72.100.181[500] spi=2319949803(0x8a479feb) > > Jan 14 19:58:03 racoon: [NAT Test]: INFO: IPsec-SA established: > > ESP xx.xx.xx.xx[500]->xx.xx.xx.xx[500] spi=173607075(0xa5908a3) > > > > Jan 14 19:58:03 racoon: INFO: Adjusting peer's encmode > > UDP-Tunnel(3)->Tunnel(1) > > Jan 14 19:58:03 racoon: INFO: Adjusting my encmode > UDP-Tunnel->Tunnel > > Jan 14 19:58:03 racoon: INFO: NAT detected -> UDP encapsulation > (ENC_MODE > > 1->3). > > Jan 14 19:58:03 racoon: [NAT Test]: INFO: IPsec-SA expired: > ESP/Tunnel > > xx.xx.xx.xx[500]->xx.xx.xx.xx[500] spi=200783270(0xbf7b5a6) > > Jan 14 19:58:03 racoon: [NAT Test]: INFO: initiate new phase 2 > negotiation: > > 38.104.0.30[4500]<=>184.72.100.181[4500] > > Jan 14 19:58:03 racoon: [NAT Test]: INFO: IPsec-SA expired: ESP > > xx.xx.xx.xx[500]->xx.xx.xx.xx[500] spi=1302379504(0x4da0bbf0) > > > > > > I has before upgrade to version 2, Pfsense 1.2.3 and was working well. > > > > The major difference there between 1.2.3 and 2.x is the latter > supports NAT-T. It's now negotiating NAT-T where obviously it's > unnecessary since it worked on 1.2.3. I've seen one other scenario > where NAT-T had to be explicitly disabled on the pfSense side after > upgrade because it inconsistently negotiated NAT-T with a Cisco on the > remote end which was causing issues at times. Disabling NAT-T should > fix it. > _______________________________________________ > List mailing list > [email protected] > http://lists.pfsense.org/mailman/listinfo/list > -- Aymen Belkhiria
_______________________________________________ List mailing list [email protected] http://lists.pfsense.org/mailman/listinfo/list
