Project

General

Profile

Actions

Bug #150

closed

IPSEC/FAST_IPSEC panic.

Added by dragonfly almost 18 years ago. Updated almost 5 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:

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

ipsec.conf (431 Bytes) ipsec.conf dragonfly, 04/22/2006 03:56 PM
ipsec.diff (1.64 KB) ipsec.diff dragonfly, 04/22/2006 03:56 PM
tcpdump_ssh (2.33 KB) tcpdump_ssh dragonfly, 04/25/2006 12:20 PM
tcpdump_vsftpd (2.13 KB) tcpdump_vsftpd dragonfly, 04/25/2006 12:20 PM
ipsec.conf.server (423 Bytes) ipsec.conf.server dragonfly, 04/25/2006 12:20 PM
ipsec.conf.client (423 Bytes) ipsec.conf.client dragonfly, 04/25/2006 12:20 PM
Actions #1

Updated by dillon almost 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.

Actions #2

Updated by dillon almost 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 &lt;port_you_are_testing_tcp_on&gt;
-Matt
Actions #3

Updated by dragonfly almost 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
:/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 :/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

Actions #4

Updated by dragonfly almost 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

Actions #5

Updated by corecode over 17 years ago

is this still present?

Actions #6

Updated by tuxillo over 10 years ago

  • Description updated (diff)
  • Assignee changed from 0 to tuxillo

Gab

Actions #7

Updated by liweitianux almost 5 years ago

  • Status changed from New to Resolved

IPSec removed.

Actions

Also available in: Atom PDF