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 <[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. > 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 [email protected] <mailto:[email protected]> /The Market Ticker/ /[S/MIME encrypted email preferred]/
smime.p7s
Description: S/MIME Cryptographic Signature
