<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I see. I know in the linux world, one could use iptables to tag packets coming in on an interface and then route the response back out of the interface they came in which would solve the issue (which I've done before to work around a similar oddball issue), but, I have no idea if that sort of low level packet manipulation is something OmniOS is capable of. If so, that'd solve the problem.<div class=""><br class=""></div><div class="">A different and ugly approach would be to have the OmniOS box use a software firewall to only allow ssh on the desired VLAN interface, enable ip forwarding in OmniOS, and then add static routes (yes plural) to your client machines as needed to use each OmniOS server as it's very own gateway to it's own management vlan ip. It's ugly, but, it could work.</div><div class=""><br class=""></div><div class="">The only other way I could think of is maybe you could run ssh in a zone and maybe that zone can have it's own independent network stack? I'm not very familiar with zone networking, so maybe it can do that, maybe not?</div><div class=""><br class=""></div><div class="">Michael</div><div class=""><div class=""><br class=""> <br class=""><div><blockquote type="cite" class=""><div class="">On Apr 7, 2016, at 11:50 AM, Schweiss, Chip <<a href="mailto:chip@innovates.com" class="">chip@innovates.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class=""><br class=""><div class="gmail_extra"><br class=""><div class="gmail_quote">On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott <span dir="ltr" class=""><<a href="mailto:mtalbott@lji.org" target="_blank" class="">mtalbott@lji.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="">Oh, I see. Sorry about that, reading it on my phone didn't render your diagram properly ;)<div class=""><br class=""></div><div class="">The reason this is happening is because the omnios box has knowledge of both subnets in its routing table and it always takes the shortest path to reach an ip destination.</div></div></blockquote><div class=""><br class=""></div><div class="">That's definitely the reason, but not correct when stateful firewalls are involved.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">So you will need to put the "clients" in a unique subnet that always passes through the firewall in both directions (in a subnet that's not shared by the omnios machines). Any attempt to add/modify a static route to the omnios box to resolve this will likely fail (it'll just move the problem from one network to the other one and cause your "services" network to route improperly).</div></div></blockquote><div class=""><br class=""></div><div class="">The problem is each person who manages these (there are 4) are also clients of the services (SMB, NFS). </div><div class=""><br class=""></div><div class="">For management, going through the firewall is fine, it is low volume, but the services need to be on the same VLAN or else the 1gb firewall will choke on the 10gb services.</div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><br class=""></div><div class="">Either that, or remove the firewall as a hop, set sshd to listen only on the management IP, and add a management vlan interface to the clients allowed to connect.<span class="HOEnZb"><font color="#888888" class=""><br class=""><div class=""><br class=""></div></font></span></div></div></blockquote><div class=""><br class=""></div><div class="">I've considered this too, but I have some floating IP attached to zfs pools in an HA cluster that SSH needs to bind to. </div><div class=""><br class=""></div><div class="">Unless I can get the network stack on the management vlan to act independently of the other interfaces, it may come to modifying the sshd_config and restarting ssh each time a pool is started or stopped on a host. </div><div class=""><br class=""></div><div class="">-Chip</div><div class=""><br class=""></div><div class=""> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><span class="HOEnZb"><font color="#888888" class=""><div class=""></div><div class="">Michael</div></font></span><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Apr 7, 2016, at 10:25 AM, Michael Talbott <<a href="mailto:mtalbott@lji.org" target="_blank" class="">mtalbott@lji.org</a>> wrote:</div><br class=""><div class=""><div dir="auto" class=""><div class="">It sounds like you're using the same subnet for management and service traffic, that would be the problem causing the split route. Give each vlan a unique subnet and traffic should flow correctly.<br class=""><br class="">Michael<br class="">Sent from my iPhone</div><div class=""><br class="">On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <<a href="mailto:chip@innovates.com" target="_blank" class="">chip@innovates.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">On several of my OmniOS hosts I have a setup a management interface for SSH access on an independent VLAN. There are service vlans attached to other nics.<div class=""><br class=""></div><div class="">The problem I am having is that when on privileged machine on one of the vlans also on the service side that has access to the management SSH port the TCP SYN comes in the management VLAN but the SYNACK goes out the service VLAN instead of routing back out its connecting port. This causes a split route and the firewall blocks the connection because the connection never appears complete.</div><div class=""><br class=""></div><div class="">Traffic is flowing like this:</div><div class=""><font face="monospace, monospace" class="">client firewall omnnios</font></div><div class=""><font face="monospace, monospace" class="">10.28.0.106 -> 10.28.0.254->10.28.125.254 -> 10.28.125.44</font></div><div class=""><font face="monospace, monospace" class=""><br class=""></font></div><div class=""><font face="monospace, monospace" class="">10.28.0.106 <--------------------------------- 10.28.0.44 </font></div><div class=""><br class=""></div><div class="">How can I cause connections to only communicate on the vlan that the connection is initiated from? </div><div class=""><br class=""></div><div class="">I don't want to use the 10.28.0.44 interface because that is a virtual IP and will not always be on the same host.</div><div class=""><br class=""></div><div class="">-Chip</div><div class=""><br class=""></div><div class=""><br class=""></div></div> </div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">OmniOS-discuss mailing list</span><br class=""><span class=""><a href="mailto:OmniOS-discuss@lists.omniti.com" target="_blank" class="">OmniOS-discuss@lists.omniti.com</a></span><br class=""><span class=""><a href="http://lists.omniti.com/mailman/listinfo/omnios-discuss" target="_blank" class="">http://lists.omniti.com/mailman/listinfo/omnios-discuss</a></span><br class=""></div></blockquote></div></div></blockquote></div><br class=""></div></div></div></div></div></blockquote></div><br class=""></div></div> </div></blockquote></div><br class=""></div></div></body></html>