On 10/16/06, J. Ryan Earl <[EMAIL PROTECTED]> wrote:
Let me explain something here since I'm not making the problem clear.
The problem has -nothing- at all to do with the Cisco firewall. The
setsockopt errors occur -well before- any communication with the other
end-point of the VPN tunnel. Case in point, I can set the other
end-point of the tunnel to be a non-existent IP address and I still get
the setsockopt errors. I tried making a tunnel to non-Cisco firewalls,
same result. Furthermore, ISAKMP NAT Transversal is definitely disabled
on the Cisco firewall as per default.
The fact of the matter is there is a disagreement of some sort between
web-configuration GUI front-end and the kernel's network back-end. The
whole IPSEC_NAT_T thing may be a redherring, but from what I can see
IPSEC_NAT_T is required for the UDP_ENCAP_ESPINUDP_NON_IKE socket option
which is in turn required for network-to-network VPN tunnels with
pre-shared keys. Software within pfSense--racoon--is trying to set an
unsupported socket option well before any communication with the remote
VPN end-point. Thus the problem is definitely within pfSense somewhere,
be it the kernel lacking support of a needed option or racoon setting a
bad socket option. I even switched from ESP to AH on Phase2, but it
still tried doing the UDP_ENCAP_ESPINUDP_NON_IKE socket option and
actually stopped the pfSense firewall from doing any NAT at all for a
minute or so.
From the quote below, it sounds like I'm the first person to try a
network-to-network VPN tunnel using a pre-shared key on the pfSense
firewall. Can anyone confirm successfully setting up a
network-to-network VPN tunnel with pre-shared key between a pfSense
firewall and any other non-pfSense firewall? If I'm missing something
let me know, but all signs point to a problem in pfSense.
Yep. It works fine with a Nortel Contivity. Again, this is a issue
where the Cisco is attempting to perform UDP encapsulation of the
tunnel (presumably for NAT-T reasons). There have been suggestions on
how to disable this on the Cisco side. It very well may be a racoon
issue (seeing as the version of racoon in use doesn't actually support
UDP_ENCAP), but there's nothing we can do to solve it. In the
meantime until there's a fix, either tell us how to make FreeBSD do
the right thing (since we don't have those annoying blue boxes to test
with), or try some of the suggestions on how to disable it on the
Cisco end.
--Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
