06-09-2004 01:27 PM
Hello,
we have problems in using long digital certificates
in the case of a Cisco VPN concentrator 3000 .
For such long digital certificates the following log is typical:
=================================================================
vpn 12846817 06/09/2004 13:45:18.940 SEV=8 IKEDBG/81 RPT=5586 IPXXXXXXX SENDING Message (msgid=0)
with payloads : HDR + KE (4) + NONCE (10) total length : 1749
vpn 12846917 06/09/2004 13:45:18.960 SEV=8 IKEDBG/81 RPT=5587 IPXXXXXXX RECEIVED Message (msgid=0)
with payloads : HDR + FRAG (132) + NONE (0) total length : 548
vpn 12846919 06/09/2004 13:45:18.960 SEV=7 IKEDBG/61 RPT=154 IPXXXXXXX Rcv'd fragment from a new
fragmentation set. Deleting any old fragments.
vpn 12846930 06/09/2004 13:45:18.960 SEV=8 IKEDBG/81 RPT=5588 IPXXXXXXX RECEIVED Message (msgid=0)
with payloads : HDR + FRAG (132) + NONE (0) total length : 548
vpn 12846938 06/09/2004 13:45:18.960 SEV=8 IKEDBG/81 RPT=5589 IPXXXXXXX RECEIVED Message (msgid=0)
with payloads : HDR + FRAG (132) + NONE (0) total length : 548
vpn 12846946 06/09/2004 13:45:18.970 SEV=8 IKEDBG/81 RPT=5590 IPXXXXXXX RECEIVED Message (msgid=0)
with payloads : HDR + FRAG (132) + NONE (0) total length : 448
vpn 12846948 06/09/2004 13:45:18.970 SEV=7 IKEDBG/63 RPT=154 IPXXXXXXX Successfully assembled an
encrypted pkt from rcv'd fragments!
vpn 12846950 06/09/2004 13:45:18.970 SEV=8 IKEDBG/81 RPT=5591 IPXXXXXXX RECEIVED Message (msgid=0)
with payloads : HDR + ID (5) + CERT (6) + CERT_REQ (7) + SIG (9) + NOTIFY (11) + NONE (0) total length : 1933
Here the length of the certificate yields a packet length of "total length : 1933" bytes
which exceeds the usual Ethernet MTU size of 1500 bytes.
We find that in the case of an IKE fragmentation of the
packet which contains the client certificate
only the session types IPSec/udp or IPSec/tcp are possible.
In contrast using a smaller certificate on the client side
which does not enforce an IKE fragmentation
all types of sessions, this means IPSec, IPSec/udp and
IPSec/tcp can be realized.
Therefore the following question:
Is the IKE fragmentation the reason for the
availability of only the IPSec/udp or IPSec/tcp session types?
The concentrator bug CSCdz30124 does not match our conditions.
Often warnings can be found in connection to IKE fragmentation:
"IKE fragmentation is a problem because most NATs will drop fragments as
will many routers (recent versions of Cisco IOS can handle this
correctly)."
http://www.pdl.cmu.edu/mailinglists/ips/mail/msg08579.html
B.Loehle
06-29-2004 09:39 AM
Hi,
Your question:
"Is the IKE fragmentation the reason for the
availability of only the IPSec/udp or IPSec/tcp session types? "
No. It should work with all... As a matter of fact,
CSCdz30124 was filed for cTCP connections (IPSEC over TCP). In your case you were able to make it to work with IPSec/udp or IPSec/tcp. We will need to investigate this in detail. What version of Concentrator code are you using? also, is this also reproducible with NAT-T --encapsulating the ESP packets with UDP port 4500, instead of the proprietory IPSEC over UDP?
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide