Re: NAT problems 14.3+
Rob Bloemers <[email protected]> Tue, 5 May 2026 16:51:29 +0200
| Newsgroups | gmane.os.freebsd.devel.ipfw |
|---|---|
| Message-ID | <[email protected]> |
ifconfig epair0b -txcsum -rxcsum on the inside of the jail works too. > On 5 May 2026, at 16:45, Rob Bloemers <[email protected]> wrote: >=20 > I found the reason, or better put, workaround for my issue. When = disabling tx and rxcsum on the vnet internet of the jail, things starts = to work again. >=20 > on the host, ifconfig vnet0.X -txcsum -rxcsum=20 >=20 >> On 4 May 2026, at 16:28, Rob Bloemers <[email protected]> = wrote: >>=20 >> FWIW >>=20 >> Avoiding in-kernel IPFW NAT and using the rc.firewall / type open = with natd in userspace, nat seems to function fine for my jails. >>=20 >>> On 3 May 2026, at 12:54, Rob Bloemers <[email protected]> = wrote: >>>=20 >>> I've tried this setup now on three different machines at three = different providers, and each time my simple NAT breaks and i'm still = clueless on the why. And it prevents me from moving quite a few machines = from 14.3 to newer releases. What works fine on 14.3 breaks on 14.4 or = newer, which even worse results on 15.0. Even the ipfw nat example from = the freebsd manual does not work. I'm sure i cant be the only one with = this issue? >>>=20 >>> Really hope somebody can replicate this for him/herself to confirm = this and/or give me a solution for my problem.=20 >>>=20 >>> Kind Regards >>> Rob=20 >>>=20 >>>> On 23 Apr 2026, at 12:34, Rob Bloemers <[email protected]> = wrote: >>>>=20 >>>> had to quickly upgrade to 14.4 again to return to the broken state. = But unfortunately -tso -lro does not change the result. >>>>=20 >>>> ice0: = flags=3D1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> = metric 0 mtu 9000 >>>> = options=3D4e00028<VLAN_MTU,JUMBO_MTU,RXCSUM_IPV6,TXCSUM_IPV6,HWSTATS,MEXTP= G> >>>>=20 >>>> using >>>> ifconfig_ice0=3D"DHCP mtu 9000 -tso -lro -vlanhwtso -vlanhwtag = -vlanhwfilter" >>>>=20 >>>> Inside the jail, the ISP dns stops responding then too strangely. = Then when i update it to 1.1.1.1 i can resolve again inside the jail. >>>> Then when i ping some domain, the first reply i get is from the = resolved ip and then i get responses from its own server ip. >>>>=20 >>>> (jail) >>>> root@x-mysql:~ # ping nu.nl >>>> PING nu.nl (2.16.245.135): 56 data bytes >>>> 64 bytes from 2.16.245.135: icmp_seq=3D0 ttl=3D50 time=3D4.603 ms >>>> 64 bytes from 57.128.x.y: icmp_seq=3D1 ttl=3D50 time=3D4.588 ms >>>> 64 bytes from 57.128.x.y: icmp_seq=3D2 ttl=3D50 time=3D4.602 ms >>>> 64 bytes from 57.128.x.y: icmp_seq=3D3 ttl=3D50 time=3D4.602 ms >>>>=20 >>>> Maybe this can be a clue? (i dont remember seeing this before = today) >>>>=20 >>>>=20 >>>>> On 23 Apr 2026, at 10:22, Andrey V. Elsukov <[email protected]> = wrote: >>>>>=20 >>>>> On 23.04.2026 11:10, Rob Bloemers wrote: >>>>>> Yes sir, via ifconfig and using sysctl.conf && fresh reboot. = Unfortunately no changed. >>>>>>>=20 >>>>>>> Did you try to disable TSO on the ice0 interface? >>>>>=20 >>>>> I'm not sure what you have disabled using sysctl.conf, can you = show the output of: >>>>>=20 >>>>> ifconfig ice0 | grep options >>>>>=20 >>>>> --=20 >>>>> WBR, Andrey V. Elsukov >>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>>=20 >>=20 >>=20 >=20 >=20