Bug 65616

Summary: IPSEC can't detunnel GRE packets after real ESP encryption
Product: Base System Reporter: Valentin Nechayev <netch>
Component: kernAssignee: Andrey V. Elsukov <ae>
Status: Closed DUPLICATE    
Severity: Affects Only Me CC: eugen
Priority: Normal    
Version: 4.9-RELEASE   
Hardware: Any   
OS: Any   

Description Valentin Nechayev 2004-04-16 12:50:23 UTC
Build simple GRE tunnel between two hosts and apply transport IPSEC ESP
between external endpoints of tunnel.
With null ESP encryption, packets are "decrypted" and appear on input of
GRE interface. With real encryption, packets are lost.
The situation is identical for three tested versions (4.9, 4.10, 5.2.1).
I say that problem is on decryption, not encryption, because some of tests
included Cisco router (75xx with RSP4, IOS 12.2(18)S4): tunnel organized
between FreeBSD and Cisco passed successfully packets from FreeBSD to host
after Cisco, but not towards.

How-To-Repeat: 
The following script was used to organize tunnel and ESP.
External addresses are 193.193.193.11 and 193.193.193.134 (real example).

=== cut ===
#!/bin/sh
set -e
IFTYPE=${1:-gif}
IFACE=${IFTYPE}0

ifconfig ${IFACE} destroy 2>/dev/null || true
ifconfig ${IFACE} create
ifconfig ${IFACE} inet 10.0.1.1 10.0.1.2
ifconfig ${IFACE} tunnel 193.193.193.11 193.193.193.134
setkey -c <<EOF
flush;
add 193.193.193.11 193.193.193.134 esp 1100 -E simple "";
add 193.193.193.134 193.193.193.11 esp 1101 -E simple "";
#add 193.193.193.11 193.193.193.134 esp 1100 -E des-cbc "NuNiFiga";
#add 193.193.193.134 193.193.193.11 esp 1101 -E des-cbc "NuNiFiga";
spdflush;
spdadd 193.193.193.11 193.193.193.134 any -P out ipsec esp/transport//use;
spdadd 193.193.193.134 193.193.193.11 any -P in ipsec esp/transport//use;
EOF
exit 0
=== end cut ===

Run it as "./makeit" without arguments to organize IPIP tunnel (using gif)
which works, and as "./makeit gre" to organize GRE tunnel which doesn't.
For another host, the same script with reverted tunnel endpoints and
SPD addresses must be used.

This can be tied with particularity of tunnel mode (packets after tunnel ESP
has the same view as packets after IPIP tunneling and transport ESP),
but IPIP tunnel has no such problems even with possible mess of these
two tunneling modes.

The question was asked some time ago in net@freebsd.org and silence was reply.
Comment 1 Bruce M Simpson freebsd_committer freebsd_triage 2004-06-16 10:11:02 UTC
Responsible Changed
From-To: freebsd-bugs->bms

I'll try to look at this
Comment 2 Bruce M Simpson freebsd_committer freebsd_triage 2006-09-23 17:29:17 UTC
Responsible Changed
From-To: bms->freebsd-net

I must focus on more specific areas.
Comment 3 Bruce M Simpson freebsd_committer freebsd_triage 2006-09-24 09:57:20 UTC
Responsible Changed
From-To: freebsd-net->gnn

by request
Comment 4 shattered 2007-08-07 14:39:51 UTC
Still happens in 5.5.

-- 
Sergey Svishchev
Comment 5 George V. Neville-Neil freebsd_committer freebsd_triage 2010-06-15 18:47:06 UTC
Responsible Changed
From-To: gnn->freebsd-net

This is likely stale.
Comment 6 Andrey V. Elsukov freebsd_committer freebsd_triage 2014-04-04 10:37:42 UTC
Responsible Changed
From-To: freebsd-net->ae

Take it.
Comment 7 Andrey V. Elsukov freebsd_committer freebsd_triage 2014-10-07 12:02:52 UTC
I tested such configuration on head/. It works for me.
Comment 8 Eugene Grosbein freebsd_committer freebsd_triage 2017-12-27 20:51:11 UTC

*** This bug has been marked as a duplicate of bug 122065 ***