No I haven't tried different algorithms yet, that was the next thing I
was going to try but I was trying to hold off on that until I had
further information. The pfSense firewall is actually a replacement for
a failed Netgear FVX538 which already had an AES-256 based VPN setup. I
was trying to preserve those settings as the PIX515e is on a production
system and I want to change as little as possible, but I will try to
drop down to less secure algorithms if that appears to be the only
option. However, there appears to be some exchange between the
firewalls. Here's a few iterations of the cycle that happens:
Oct 14 12:36:58 racoon: INFO: initiate new phase 1 negotiation:
216.62.203.233[500]<=>206.127.8.197[500]
Oct 14 12:36:58 racoon: INFO: begin Identity Protection mode.
Oct 14 12:36:58 racoon: INFO: received Vendor ID:
draft-ietf-ipsra-isakmp-xauth-06.txt
Oct 14 12:36:58 racoon: INFO: received Vendor ID: DPD
Oct 14 12:36:58 racoon: INFO: received Vendor ID: CISCO-UNITY
Oct 14 12:37:07 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:37:07 racoon: INFO: delete phase 2 handler.
Oct 14 12:37:20 racoon: INFO: request for establishing IPsec-SA was
queued due to no phase1 found.
Oct 14 12:37:29 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:37:29 racoon: INFO: delete phase 2 handler.
Oct 14 12:37:42 racoon: INFO: request for establishing IPsec-SA was
queued due to no phase1 found.
Oct 14 12:37:51 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:37:51 racoon: INFO: delete phase 2 handler.
Oct 14 12:37:58 racoon: ERROR: phase1 negotiation failed due to time
up. 4c0f83756ba7c7cc:237eb55e492c3461
Oct 14 12:38:04 racoon: INFO: IPsec-SA request for 206.127.8.197
queued due to no phase1 found.
Oct 14 12:38:04 racoon: INFO: initiate new phase 1 negotiation:
216.62.203.233[500]<=>206.127.8.197[500]
Oct 14 12:38:04 racoon: INFO: begin Identity Protection mode.
Oct 14 12:38:04 racoon: INFO: received Vendor ID:
draft-ietf-ipsra-isakmp-xauth-06.txt
Oct 14 12:38:04 racoon: INFO: received Vendor ID: DPD
Oct 14 12:38:04 racoon: INFO: received Vendor ID: CISCO-UNITY
Oct 14 12:38:13 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:38:13 racoon: INFO: delete phase 2 handler.
Oct 14 12:38:26 racoon: INFO: request for establishing IPsec-SA was
queued due to no phase1 found.
Oct 14 12:38:35 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:38:35 racoon: INFO: delete phase 2 handler.
Oct 14 12:38:48 racoon: INFO: request for establishing IPsec-SA was
queued due to no phase1 found.
Oct 14 12:38:57 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:38:57 racoon: INFO: delete phase 2 handler.
Oct 14 12:39:04 racoon: ERROR: phase1 negotiation failed due to time
up. 0f2d11d859b2019d:237eb55e14e46837
Oct 14 12:39:10 racoon: INFO: IPsec-SA request for 206.127.8.197
queued due to no phase1 found.
Oct 14 12:39:10 racoon: INFO: initiate new phase 1 negotiation:
216.62.203.233[500]<=>206.127.8.197[500]
Oct 14 12:39:10 racoon: INFO: begin Identity Protection mode.
Oct 14 12:39:10 racoon: INFO: received Vendor ID:
draft-ietf-ipsra-isakmp-xauth-06.txt
Oct 14 12:39:10 racoon: INFO: received Vendor ID: DPD
Oct 14 12:39:10 racoon: INFO: received Vendor ID: CISCO-UNITY
Oct 14 12:39:19 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:39:19 racoon: INFO: delete phase 2 handler.
Oct 14 12:39:32 racoon: INFO: request for establishing IPsec-SA was
queued due to no phase1 found.
Oct 14 12:39:41 racoon: ERROR: phase2 negotiation failed due to time
up waiting for phase1. ESP 206.127.8.197[500]->216.62.203.233[500]
Oct 14 12:39:41 racoon: INFO: delete phase 2 handler.
Now all I see are timeouts for Phase1. I don't see any mismatches. The
only errors I see are on local socket setup:
*racoon: WARNING: setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid
argument *
The above is what I think is specifically causing the problem, and this
happens before Phase1 immediately after applying VPN settings. I don't
know exactly what this setsockopt() call is supposed to do, but it looks
like racoon is trying to enable an option that the BSD kernel doesn't
support. From a little googling, it looks like IPSEC_NAT_T support
needs to be compiled into the BSD kernel for this to work. I'm more of
a Linux guy, is there someway to check for this in the pfSense kernel?
Do other pfSense users get this error on working VPN tunnels?
On the PIX515e side, I'm not sure what logging information to give you,
not exactly a Cisco expert. When I do a 'show ipsec sa' no security
association has been setup. There's no SPI or ESP information. Do you
want packet logging or something?
-ryan
Captain Bablam wrote:
> Good morning Ryan,
> Can you send the pix debugs as well? I think you are right, this
> looks like a phase 1 setup problem, it maybe that PF and the pix are
> having trouble playing nice on the negotiation of your current phase 1
> params. If you send the pix debugs I think I will have a better idea
> of where the negotiation is failing. Also did you try different hash
> and encryption algs for phase 1 as a test?
>
> Wade B
>
> On 10/14/06, J. Ryan Earl <[EMAIL PROTECTED]> wrote:
>
>> I'm trying out a pfSense based firewall for my local office, and I'm
>> trying to setup a VPN to a Cisco PIX 515e in one of our production
>> datacenters. I believe I am encountering some sort of error on the
>> pfSense firewall. Stage1 exchange continually times out. I've
>> quadruple checked all of the VPN parameters on both side and they are
>> consistent. I notice whenever I "apply" VPN changes I get the
following
>> errors at the beginning of the VPN system log:
>>
>> Oct 14 11:19:53 racoon: INFO: @(#)ipsec-tools 0.6.6
>> (http://ipsec-tools.sourceforge.net)
>> Oct 14 11:19:53 racoon: INFO: @(#)This product linked OpenSSL
>> 0.9.7e-p1 25 Oct 2004 (http://www.openssl.org/)
>> Oct 14 11:19:53 racoon: INFO: fe80::1%lo0[500] used as isakmp
port
>> (fd=13)
>> Oct 14 11:19:53 racoon: INFO: ::1[500] used as isakmp port
(fd=14)
>> Oct 14 11:19:53 racoon: INFO: 127.0.0.1[500] used as isakmp port
>> (fd=15)
>> Oct 14 11:19:53 racoon: WARNING:
>> setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument
>> Oct 14 11:19:53 racoon: INFO: 192.168.2.254[500] used as
isakmp port
>> (fd=16)
>> Oct 14 11:19:53 racoon: WARNING:
>> setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument
>> Oct 14 11:19:53 racoon: INFO: fe80::250:daff:fe28:ca4%xl2[500]
used
>> as isakmp port (fd=17)
>> Oct 14 11:19:53 racoon: INFO: 216.62.203.233[500] used as isakmp
>> port (fd=18)
>> Oct 14 11:19:53 racoon: WARNING:
>> setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument
>> Oct 14 11:19:53 racoon: INFO: fe80::201:2ff:fe3f:58a7%xl1[500]
used
>> as isakmp port (fd=19)
>> Oct 14 11:19:53 racoon: INFO: 209.198.142.210[500] used as isakmp
>> port (fd=20)
>> Oct 14 11:19:53 racoon: WARNING:
>> setsockopt(UDP_ENCAP_ESPINUDP_NON_IKE): Invalid argument
>> Oct 14 11:19:53 racoon: INFO: fe80::201:2ff:fe3c:a553%xl0[500]
used
>> as isakmp port (fd=21)
>>
>> I'm thinking this is the root cause of my problem, not a
difference in
>> configuration between the VPN tunnel end-points. Does anyone know
what
>> would cause this and how to fix it?
>>
>> Thank in advance,
>> -ryan
>>
>> ---------------------------------------------------------------------
>> 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]
