[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