Date: Fri, 9 Dec 2016 21:23:01 -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: <d3bfafc7-c4ad-7984-546b-6b95f8d6d577@denninger.net> In-Reply-To: <01fbc965-f5bc-0f62-eb89-02e097e03cf7@denninger.net> References: <099203a1-f601-bb79-548d-27c62fcbf556@denninger.net> <005b34c8-2217-fa06-5584-6999022481a3@denninger.net> <156E272C-0EFA-4A15-8544-C580AAEB6033@obsigna.com> <01fbc965-f5bc-0f62-eb89-02e097e03cf7@denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
On 12/9/2016 07:16, Karl Denninger wrote:
> 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.
>
I have completely re-factored the IPFW rule set that I am using here (it
was formerly built on top of the
"Simple" config in /etc/rc.firewall) to be completely stand-alone and
the problem has disappeared.
Bottom line -- this appears to have been some sort of problem with the
rule set rather than ipfw itself.
--
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
[-- Attachment #2 --]
0 *H
010
`He 0 *H
_0[0C)0
*H
01 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA0
150421022159Z
200419022159Z0Z1 0 UUS10UFlorida10U
Cuda Systems LLC1 0 UKarl 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|e f"V لio74zn">a1qWuɖbFeGE&3(KhixG3!#e_XƬ Ϝ/,$+;4y 'Bz<qT9_?rRUpn5
Jn&Rx/p Jyel*pN8/#9u/YP EC)TY>~/˘N[vyiDKˉ ,^" ?$T8 v& K%z8C @?K{9f`+@,| Mbia 007++0)0'+0http://cudasystems.net:88880 U 0 0 `HB0 U 0, `HB
OpenSSL Generated Certificate0 U -h\Ff Y0 U #0$q}ݽʒm50 U 0karl@denninger.net0
*H
Owbabɺx&Uk[ (Oj!%p MQ0I!#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# }D Z9;V9#>Sw"[UP710001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
`He M0 *H
1 *H
0 *H
1
161210032301Z0O *H
1B@ճ`t=MtL-`E
^֑U[d$oZ>`B1-
80l *H
1_0]0 `He*0 `He0
*H
0*H
0
*H
@0+0
*H
(0 +71001 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0 *H
101 0 UUS10UFlorida10U Niceville10U
Cuda Systems LLC1 0UCuda Systems LLC CA1"0 *H
Cuda Systems LLC CA)0
*H
}n,Zb~s fm
Gfy澣ֆoLJ^̼i<5
we R
/Ȥ(*: )[3SBPa HD m`"NA sE7@φ= T.Y?gkecw.ƘlT3` ղ??<p)S`
Sf|*ΐዕDеK^@R!(MEXKLct N' 'S
5ľ B>/$e+9@Q jKO!`źdO0v#'nWuR)gE,GeI "*` иʲi]:? 9wzFUAlio 23nJbvJ īKXvh-L{AY 1w b H,"ՠoh)^d{̠F+u;-d=N.rLEfxW o{%
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?d3bfafc7-c4ad-7984-546b-6b95f8d6d577>