Skip site navigation (1)Skip section navigation (2) 
Date:      Fri, 9 Dec 2016 07:16:47 -0600
From:      Karl Denninger <karl@denninger.net>
To:        freebsd-ipfw@freebsd.org
Subject:   Re: IPFW problem with passing IPSEC through in-kernel NAT
Message-ID:  <01fbc965-f5bc-0f62-eb89-02e097e03cf7@denninger.net>
In-Reply-To: <156E272C-0EFA-4A15-8544-C580AAEB6033@obsigna.com>
References:  <099203a1-f601-bb79-548d-27c62fcbf556@denninger.net> <005b34c8-2217-fa06-5584-6999022481a3@denninger.net> <156E272C-0EFA-4A15-8544-C580AAEB6033@obsigna.com>
next in thread | previous in thread | raw e-mail | index | archive | help 

[-- Attachment #1 --]
On 12/9/2016 06:18, Dr. Rolf Jansen wrote:
>> Am 09.12.2016 um 02:11 schrieb Karl Denninger <karl@denninger.net>:
>> ...
>> Some more information on this issue.... I suspect that something is
>> getting mangled somewhere in the IP stack, perhaps related to hardware
>> checksumming or similar -- or in the ipfw code.
> I had always ran into IPsec-NAT-UDP checksumming issues since I started working with FreeBSD, that tim v8.0. With a rather simple change in the respective kernel source file at least my issue can be resolved. This may be related to your issue or even not, anyway, I guess it is worth to give it a try.
>
> I am now running FreeBSD 11-RELEASE-p5. On line 462 of file /usr/src/sys/netinet/udp_usrreq.c, I replaced:
>
>     if (uh->uh_sum) {
>
> with:
>
>     if (uh->uh_sum &&
>         uh->uh_dport != htons(1701) &&
>         uh->uh_dport != htons(4500)) {
>
> This effectively skips extended UDP checksumming for certain UDP ports -- here the L2TP and IPsec-NAT-T ports. When I investigated the issue, I found in one related RFC, that IPsec-NAT-T isn't supposed to do UDP checksumming on the encapsulated packets anyway, and my patch enforces this behaviour.
>
> Best regards
>
> Rolf
>

In this case is that I never get to the use of port 4500 (there are no
packets emitted on that port that I can find); the initial key exchange
on port 500 is failing, and in-kernel NAT appears to be involved in some
fashion because I'm getting inside addresses that are (in some cases)
not being NATted at all despite the fact that as far as I can tell they
*should* be.

I'm going to spend some time refactoring the IPFW rule set to
compartmentalize the various paths through it more-fully.  Perhaps that
will shed some more light on the problem, or at least make
more-reasonable an attempt to trace it.

-- 
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/

[-- Attachment #2 --]
0	*H
010
	`He0	*H
_0[0C)0
	*H
010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z10	UUS10UFlorida10U
Cuda Systems LLC10UKarl Denninger (OCSP)0"0
	*H
0
X@vkY
Tq/vE]5#֯MX\8LJ/V?5Da+
sJc*/r{ȼnS+w")ąZ^DtdCOZ ~7Q '@a#ijc۴oZdB&!Ӝ-<	?HN5y
5}F|ef゘"Vلio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬϜ/,$+;4y'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YPEC)TY>~/˘N[vyiDKˉ,^" ?$T8v&K%z8C @?K{9f`+@,|Mbia007++0)0'+0http://cudasystems.net:88880	U00	`HB0U0,	`HB
OpenSSL Generated Certificate0U-h\Ff Y0U#0$q}ݽʒm50U0karl@denninger.net0
	*H
Owbabɺx&Uk[(Oj!%pMQ0I!#QH}.>~2&D}<wm_>V6v]f>=Nn+8;q wfΰ/RLyUG#b}n!Dր_up|_ǰc/%ۥ
nN8:d;-UJd/m1~VނיnN I˾$tF1&}|?q?\đXԑ&\4V<lKۮ3%Am_(q-(cAeGX)f}-˥6cv~Kg8m~v;|9:-iAPқ6ېn-.)<[$KJtt/L4ᖣ^Cmu4vb{+BG$M0c\[MR|0FԸP&78"4p#}DZ9;V9#>Sw"[UP7100010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0
	`HeM0	*H
	1	*H
0	*H
	1
161209131647Z0O	*H
	1B@u84O$6lv#)pԝL-L)bZD@TCE3SaXJ_cCns0l	*H
	1_0]0	`He*0	`He0
*H
0*H
0
*H
@0+0
*H
(0	+710010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0*H
	1010	UUS10UFlorida10U	Niceville10U
Cuda Systems LLC10UCuda Systems LLC CA1"0 	*H
	Cuda Systems LLC CA)0
	*H
W\&z@!=k="ϵbH]z͆sJ̒艖W͸.O,C{op#@6K'42yȿv.ȩl>NhY
-HO)l'SU.pT"F?È'LXk)JdQjt#*
FK)NN<,0.@[q)m_It#9
AK6p$^e۳D+޽e.-W'^+0?]E0MVg<I)]W|YAh[Ю>zt~:7*x	0p9GO~+	wD
|) FD9sԺ(d$LK޸qiT|y@/دX&8"R!8K7(^)`:-WRR~8) ۄ.vc_Lr9M?Іχ8@ibȑd

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01fbc965-f5bc-0f62-eb89-02e097e03cf7>