[Bug 203630] [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or hyperv netsvc driver

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=203630

            Bug ID: 203630
           Summary: [Hyper-V] [nat] [tcp] 10.2 NAT bug in TCP stack or
                    hyperv netsvc driver
           Product: Base System
           Version: 10.2-RELEASE
          Hardware: arm64
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: kern
          Assignee: freebsd-bugs at FreeBSD.org
          Reporter: kjcamann.lists at gmail.com

I have encountered a bug in FreeBSD 10.2 (and also -CURRENT) when using NAT
with either pf or ipfw. My setup for the gateway host is:

* Microsoft Client Hyper-V on Windows 10 host machine
* FreeBSD 10.2 Release (no upgrades or updates)
* Two network interfaces, hn0 (the LAN "private switch") and hn1 (the gateway
"external switch")
* A simple pf.conf:
nat on hn1 inet from hn0:network to any -> (hn1)
pass all

I tried the equivalent for ipfw, i.e., setting firewall_type to "open" and the
and nat interface to hn1.

Both configurations work fine in FreeBSD 10.1 Release, using the exact same
Hyper-V setup. On FreeBSD 10.2 (and -CURRENT), connections to the Internet from
the gateway itself are working, but other VMs forwarding through the gateway
from the LAN while using NAT does not work. I have done some basic
investigation, including disabling the checksum and TSO offloading options (via
ifconfig) that were added to the netsvc driver for 10.2 (in R285236), but that
didn't help.

Whatever it is, it is in a common code path shared by pf and ipfw, or perhaps
the netsvc driver. In looking around the Internet, I saw a few unanswered posts
(which predate 10.2) about pf mysteriously dropping state and TCP connections
entering the SYN_SENT:CLOSED state immediately. That is the symptom I see in
10.2. The outbound NAT translation is successful, and tcpdump shows the packets
being sent out of the external interface. But then nothing else happens (no
response from the server seems to come back), and the state is dropped. This
problem is easy for me to reproduce; it happens on any new Hyper-V VM I create
with 10.2 Release, and likewise it always works fine with 10.1 Release.

-- 
You are receiving this mail because:
You are the assignee for the bug.