On 12/9/2016 06:18, Dr. Rolf Jansen wrote: >> Am 09.12.2016 um 02:11 schrieb Karl Denninger <[email protected]>: >> ... >> 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 [email protected] <mailto:[email protected]> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
