Bug #150
closedIPSEC/FAST_IPSEC panic.
0%
Description
I have been experiencing panics when testing IPSEC under HEAD. The
Kernel panics when sending or receiving Authentication Headers (AH) and
TCP connections encapsulated in ESP time out.
I've made some progress resolving the panic but I can't get IPSEC or
FAST_IPSEC to work correctly. I've gone through the ipsec code looking
for any glaring errors. Any help would be appreciated.
Regards
Gary
Communication between DragonFly Head and FreeBSD 4/6 using IPSEC.
options IPSEC
options IPSEC_ESP
IPSEC AH ICMP, UDP and TCP are working between PCs.
IPSEC ESP ICMP and UDP work. TCP connections time out.
IPSEC AH-ESP ICMP and UDP work. TCP connections time out.
options FAST_IPSEC
IPSEC AH Kernel panic.
IPSEC ESP ICMP, UDP and TCP are working between PCs.
IPSEC AH-ESP Kernel panic.
Files
Updated by dillon over 18 years ago
:I have been experiencing panics when testing IPSEC under HEAD. The
:Kernel panics when sending or receiving Authentication Headers (AH) and
:TCP connections encapsulated in ESP time out.
:
:I've made some progress resolving the panic but I can't get IPSEC or
:FAST_IPSEC to work correctly. I've gone through the ipsec code looking
:for any glaring errors. Any help would be appreciated.
:
:Regards
:
:Gary
:
:Communication between DragonFly Head and FreeBSD 4/6 using IPSEC.
I'll commit your patch, that header length check was clearly broken.
I'll try to get a test rig set up for FreeBSD<->DragonFly communication.
DragonFly<->DragonFly communication seems to work for both UDP and TCP
using your IPSEC configuration. I'm not an IPSEC expert, though, so
I'm hoping Jeffrey will step in here and figure it out.
FAST_IPSEC is likely completely broken, I would not use it at all.
-Matt
:options IPSEC
:options IPSEC_ESP
:
:IPSEC AH ICMP, UDP and TCP are working between PCs.
:IPSEC ESP ICMP and UDP work. TCP connections time out.
:IPSEC AH-ESP ICMP and UDP work. TCP connections time out.
:
:
:options FAST_IPSEC
:
:IPSEC AH Kernel panic.
:IPSEC ESP ICMP, UDP and TCP are working between PCs.
:IPSEC AH-ESP Kernel panic.
Updated by dillon over 18 years ago
:I have been experiencing panics when testing IPSEC under HEAD. The
:Kernel panics when sending or receiving Authentication Headers (AH) and
:TCP connections encapsulated in ESP time out.
:
:I've made some progress resolving the panic but I can't get IPSEC or
:FAST_IPSEC to work correctly. I've gone through the ipsec code looking
:for any glaring errors. Any help would be appreciated.
:
:Regards
:
:Gary
:
:Communication between DragonFly Head and FreeBSD 4/6 using IPSEC.
:
:
:options IPSEC
:options IPSEC_ESP
:
:IPSEC AH ICMP, UDP and TCP are working between PCs.
:IPSEC ESP ICMP and UDP work. TCP connections time out.
:IPSEC AH-ESP ICMP and UDP work. TCP connections time out.
I tested your config file between a FreeBSD-6.x and a DragonFly
box and ICMP, UDP, and TCP seems to work.
Could you explain the TCP timeout issue more? Does TCP work initially
and then fail at some point after the connection has been working for
a whlie ? I need to be able to duplicate the problem to track it down.
It might also help to use tcpdump to observe the packet traffic at the
point where the connection starts to fail and times out.
tcpdump -s 4096 -vvv -i em0 -n -l port <port_you_are_testing_tcp_on>
-Matt
Updated by dragonfly over 18 years ago
Matthew Dillon wrote:
Could you explain the TCP timeout issue more? Does TCP work initially
and then fail at some point after the connection has been working for
a whlie ? I need to be able to duplicate the problem to track it down.It might also help to use tcpdump to observe the packet traffic at the
point where the connection starts to fail and times out.tcpdump -s 4096 -vvv -i em0 -n -l port <port_you_are_testing_tcp_on>
-Matt
I was able to setup another DragonFly box and configure IPSEC between
two DragonFly machines. FTP, DNS and PING (8000 bytes) worked between
the PCs but ssh did not (Same timeout errors). I have enabled
IPSEC_DEBUG but there is no diagnostic output. All PCs are built without
IPv6 support. (I'll test again with it enabled.)
Server:
192.168.20.4
DragonFly fire.local 1.5.3-DEVELOPMENT DragonFly 1.5.3-DEVELOPMENT #0:
Sun Apr 23 18:27:00 BST 2006
gary@fire.local:/usr/obj/usr/src/sys/BUILD-IPSEC i386
fire ~ # sockstat -4 -l
USER COMMAND PID FD PROTO LOCAL ADDRESS FOREIGN ADDRESS
root vsftpd 642 3 tcp4 :21 *:
root sendmail 592 4 tcp4 127.0.0.1:25 :*
root sshd 583 3 tcp4 *:22 *:
bind named 307 20 udp4 192.168.20.4:53 :*
bind named 307 21 tcp4 192.168.20.4:53 *:
bind named 307 22 udp4 127.0.0.1:53 :*
bind named 307 23 tcp4 127.0.0.1:53 *:
bind named 307 24 udp4 :1024 *:
bind named 307 25 tcp4 127.0.0.1:953 *:*
Client:
192.168.20.6
FreeBSD lappy.local 6.0-RELEASE-p6 FreeBSD 6.0-RELEASE-p6 #1: Wed Apr 19
15:55:17 UTC 2006 root@lappy.local:/usr/obj/usr/src/sys/BUILD i386
When using FreeBSD 4.11 or 6.0 as a client UDP and ICMP connections work
but TCP connections to vsftpd and ssh time out. The ssh connections are
partially successful as the server displays the message.
Apr 25 17:48:59 fire sshd708: fatal: Timeout before authentication for
192.168.20.6
Thanks
Gary
Updated by dragonfly over 18 years ago
Matthew Dillon wrote:
I tested your config file between a FreeBSD-6.x and a DragonFly
box and ICMP, UDP, and TCP seems to work.Could you explain the TCP timeout issue more? Does TCP work initially
and then fail at some point after the connection has been working for
a whlie ? I need to be able to duplicate the problem to track it down.It might also help to use tcpdump to observe the packet traffic at the
point where the connection starts to fail and times out.tcpdump -s 4096 -vvv -i em0 -n -l port <port_you_are_testing_tcp_on>
-Matt
I have been able to 100% reproduce the following panic when using IPSEC
(3DES/SHA1 ESP no AH) between WinXP and DragonFly. From the WinXP
machine ping and DNS work but attempting to SSH (PuTTY) into DragonFly
always produces the panic.
panic: TCP header not in one mbuf: m->m_len 20
..
tcp_input(...)
esp4_input(...)
transport_processing_oncpu(...)
ip_input(...)
ip_input_handler(...)
netmsg_service_loop(...)
lwkt_exit()
Debugger("panic")
I have core dumps if anyone wants them. (Send me a direct email.)
Regards
Gary
Updated by tuxillo about 11 years ago
- Description updated (diff)
- Assignee changed from 0 to tuxillo
Gab