[OmniOS-discuss] strangeness ssh into omnios from oi_151a9
Richard PALO
richard at netbsd.org
Mon Aug 24 14:35:24 UTC 2015
Le 24/08/15 16:26, Eric Sproul a écrit :
> On Sun, Aug 23, 2015 at 9:19 PM, Dan McDonald <danmcd at omniti.com> wrote:
>> I'm not seeing it. Do you maybe have PathMTU issues, or are these same-subnet machines?
>
> This sounds a lot like a split-path routing issue, so knowing whether
> these machines are on the same subnet would be key.
>
> I've had this happen in the past with multi-homed machines, where the
> initiating TCP client's packets traverse a router/firewall with
> stateful filtering and "hair-pin" back onto the local subnet (perhaps
> due to DNAT or other fancy tricks). Since the destination knows it is
> directly connected to the network of the source IP, it responds
> directly back to the client, bypassing the router. Thus the stateful
> firewall sees only one half of the connection, and misses any
> negotiated changes, e.g. TCP window-scaling that might occur. As soon
> as the client sends a scaled-window packet, the firewall drops it as
> invalid, and the client experiences a hang in connectivity. The
> solution of course is, Don't Do That(tm). Multi-homing should be
> employed along with split-horizon DNS or firewall routing rules that
> NAT the source to ensure responses come back through the router.
>
> But maybe all this is moot if you're not multi-homing or doing
> anything similarly "fancy" between your OI and OmniOS hosts.
>
> Eric
>
>
Hi Eric,
The machines do not belong to the same subnet. They are physically remote
and the omnios machine is behind a router with port forwarding.
The OI machine *is* multihomed, though.
What strikes me most is that previous versions of omnios (and the gate)
worked fine, it is only now I just happened to come across this PITA-ful issue)
What could cause this difference in treatment, and is OI at fault or recent gate?
--
Richard PALO
More information about the OmniOS-discuss
mailing list