I am trying to setup an IPV4 IPSEC tunnel between two systems with the
following topology:
192.168.1.0/24
|
gw1 (2.6.0-test9-bk7)
|
66.22.66.22
|
Internet
|
44.33.44.33
|
gw2 (2.6.0-test9-bk9)
|
172.16.100.100/24
Both firewalls are RedHat 9 based installs, running stock 2.6.0-test9
kernels (note the variance on bk7 and bk9). Both are running Shorewall
1.4.7c to setup iptables/netfilter firewalling.
If I configure the SAD and SPDs on gw2, than setup them up on gw1, gw2
Oops hard on __xfrm4_state_lookup. I have not yet hand copied the
entire dump but have the initial pertinent
info:
EIP is at __xfrm4_state_lookup+0x6f/0xa0
Call Stack is:
xfrm_state_lookup
xfrm_rcv_encap
match [ ipt_conntrack ]
match [ ipt_state ]
ipt_do_table [ ip_tables ]
ip_local_deliver
ipt_hook [ iptable_filter]
xfrm4_rcv
ip_local_deliver_finish
ip_local_deliver_finish
nf_hook_slow
ip_load_deliver_finish
ip_local_deliver
ip_local_deliver_finish
ip_rcv_finish
ip_rcv_finish
nf_hook_slow
Between reproductions of the crash (which are easy to repeat - that's
good.... I guess..) the constant is that it's dying in the
xfrm_state_lookup area. gw1 (the bk7 system) has not crashed in any way.
tcpdump output on gw2 watching traffic to/from gw1 right at a crash:
17:02:42.147923 66.22.66.22 > 44.33.44.33: ESP(spi=0x00000201,seq=0x1) (DF)
17:02:42.147923 truncated-ip - 16 bytes missing! 66.22.66.22 >
69.0.0.84: truncated-ip - 16268 bytes missing! 44.33.44.33 > 69.0.0.84:
xns-idp (frag 13060:16352@30720) (ipip-proto-4)
17:02:43.147660 66.22.66.22 > 44.33.44.33: ESP(spi=0x00000201,seq=0x2) (DF)
17:02:43.147660 truncated-ip - 16 bytes missing! 66.22.66.22 >
69.0.0.84: bad-hlen 0 (ipip-proto-4)
17:02:44.146738 66.22.66.22 > 44.33.44.33: ESP(spi=0x00000201,seq=0x3) (DF)
17:02:44.146738 truncated-ip - 16 bytes missing! 66.22.66.22 >
69.0.0.84: bad-hlen 8 (ipip-proto-4)
/sbin/lsmod:
Module Size Used by
xfrm_user 15300 -
md5 3936 -
aes 32544 -
des 11616 -
ah4 7776 -
esp4 10496 -
af_key 32848 -
autofs 15456 -
serial_cs 8136 -
8250 20960 -
serial_core 22240 -
3c574_cs 13804 -
parport_pc 27240 -
parport 43016 -
ipt_ULOG 6440 -
ipt_ttl 1824 -
ipt_TOS 2432 -
ipt_tos 1504 -
ipt_TCPMSS 4224 -
ipt_tcpmss 2176 -
ipt_state 1824 -
ipt_REJECT 6816 -
ipt_REDIRECT 2080 -
ipt_recent 10668 -
ipt_pkttype 1504 -
ipt_physdev 2064 -
ipt_owner 3104 -
ipt_multiport 1920 -
ipt_MASQUERADE 3584 -
ipt_MARK 1984 -
ipt_mark 1568 -
ipt_mac 1856 -
ipt_LOG 5472 -
ipt_limit 2272 -
ipt_length 1600 -
ipt_helper 2048 -
ipt_esp 1856 -
ipt_ECN 3200 -
ipt_ecn 2112 -
ipt_DSCP 2464 -
ipt_dscp 1568 -
ipt_conntrack 2432 -
ipt_ah 1856 -
ip_queue 10584 -
ip_nat_tftp 3344 -
ip_nat_snmp_basic 11588 -
ip_nat_irc 4112 -
ip_nat_ftp 4752 -
ip_nat_amanda 2940 -
ip_conntrack_tftp 3508 -
ip_conntrack_irc 71220 -
ip_conntrack_ftp 72084 -
ip_conntrack_amanda 69796 -
arpt_mangle 2336 -
arptable_filter 1984 -
arp_tables 12512 -
iptable_nat 21964 -
ip_conntrack 31536 -
iptable_mangle 2720 -
iptable_filter 2688 -
ip_tables 16128 -
hid 24992 -
uhci_hcd 31184 -
usbcore 107772 -
My manual tunnel config:
#!/sbin/setkey -f
# Flush the SAD and SPD
flush;
spdflush;
# ESP SAs doing encryption using 192 bit long keys (168 + 24 parity)
# and authentication using 128 bit long keys
add 66.22.66.22 44.33.44.33 esp 0x201 -m tunnel -E 3des-cbc
0x12d49767b12e4565d5fb95bf1d5248db93c60a90d7602a44 -A hmac-md5
0x2013c28f56dea12fae2835b3654d60a2;
add 44.33.44.33 66.22.66.22 esp 0x301 -m tunnel -E 3des-cbc
0x40127f0a79fda7311b3c5344f5d5bd9a0fcd8bd926caae5f -A hmac-md5
0xd1b9a27cb7ab9562a0c8ad21f82be8b8;
# Security policies
spdadd 192.168.1.0/24 172.16.100.0/24 any -P out ipsec
esp/tunnel/66.22.66.22-44.33.44.33/require;
spdadd 172.16.100.0/24 192.168.1.0/24 any -P in ipsec
esp/tunnel/44.33.44.33-66.22.66.22/require;
/sbin/setkey -D:
44.33.44.33 66.22.66.22
esp mode=tunnel spi=769(0x00000301) reqid=0(0x00000000)
E: 3des-cbc 40127f0a 79fda731 1b3c5344 f5d5bd9a 0fcd8bd9 26caae5f
A: hmac-md5 d1b9a27c b7ab9562 a0c8ad21 f82be8b8
seq=0x00000000 replay=0 flags=0x00000000 state=mature
created: Nov 4 16:43:39 2003 current: Nov 4 16:44:35 2003
diff: 56(s) hard: 0(s) soft: 0(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=1 pid=3930 refcnt=0
66.22.66.22 44.33.44.33
esp mode=tunnel spi=513(0x00000201) reqid=0(0x00000000)
E: 3des-cbc 12d49767 b12e4565 d5fb95bf 1d5248db 93c60a90 d7602a44
A: hmac-md5 2013c28f 56dea12f ae2835b3 654d60a2
seq=0x00000000 replay=0 flags=0x00000000 state=mature
created: Nov 4 16:43:39 2003 current: Nov 4 16:44:35 2003
diff: 56(s) hard: 0(s) soft: 0(s)
last: hard: 0(s) soft: 0(s)
current: 0(bytes) hard: 0(bytes) soft: 0(bytes)
allocated: 0 hard: 0 soft: 0
sadb_seq=0 pid=3930 refcnt=0
/sbin/setkey -D -P:
172.16.100.0/24[any] 192.168.1.0/24[any] any
in ipsec
esp/tunnel/44.33.44.33-66.22.66.22/require
created: Nov 4 16:43:39 2003 lastused:
lifetime: 0(s) validtime: 0(s)
spid=8 seq=1 pid=3931
refcnt=1
192.168.1.0/24[any] 172.16.100.0/24[any] any
out ipsec
esp/tunnel/66.22.66.22-44.33.44.33/require
created: Nov 4 16:43:39 2003 lastused:
lifetime: 0(s) validtime: 0(s)
spid=1 seq=0 pid=3931
refcnt=1
On Tue, 4 Nov 2003, David T Hollis wrote:
> Both firewalls are RedHat 9 based installs, running stock 2.6.0-test9
> kernels (note the variance on bk7 and bk9). Both are running Shorewall
> 1.4.7c to setup iptables/netfilter firewalling.
Nothing obvious has changed between these snapshots which would
cause this. Are the filtering rules the same at each gateway?
Are you able to reproduce the problem without any filtering rules?
>
> If I configure the SAD and SPDs on gw2, than setup them up on gw1, gw2
> Oops hard on __xfrm4_state_lookup. I have not yet hand copied the
> entire dump but have the initial pertinent
> info:
>
> EIP is at __xfrm4_state_lookup+0x6f/0xa0
If you compile your kernel with -g, you should be able to find the
corresponding line of code (e.g. with addr2line).
- James
--
James Morris
<[email protected]>