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.
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. 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? Michael > On Apr 7, 2016, at 11:50 AM, Schweiss, Chip <[email protected]> wrote: > > > > On Thu, Apr 7, 2016 at 12:51 PM, Michael Talbott <[email protected] > <mailto:[email protected]>> wrote: > Oh, I see. Sorry about that, reading it on my phone didn't render your > diagram properly ;) > > 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. > > That's definitely the reason, but not correct when stateful firewalls are > involved. > > 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). > > The problem is each person who manages these (there are 4) are also clients > of the services (SMB, NFS). > > 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. > > > 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. > > > 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. > > 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. > > -Chip > > > Michael > > >> On Apr 7, 2016, at 10:25 AM, Michael Talbott <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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. >> >> Michael >> Sent from my iPhone >> >> On Apr 7, 2016, at 8:52 AM, Schweiss, Chip <[email protected] >> <mailto:[email protected]>> wrote: >> >>> 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. >>> >>> 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. >>> >>> Traffic is flowing like this: >>> client firewall omnnios >>> 10.28.0.106 -> 10.28.0.254->10.28.125.254 -> 10.28.125.44 >>> >>> 10.28.0.106 <--------------------------------- 10.28.0.44 >>> >>> How can I cause connections to only communicate on the vlan that the >>> connection is initiated from? >>> >>> 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. >>> >>> -Chip >>> >>> >>> _______________________________________________ >>> OmniOS-discuss mailing list >>> [email protected] <mailto:[email protected]> >>> http://lists.omniti.com/mailman/listinfo/omnios-discuss >>> <http://lists.omniti.com/mailman/listinfo/omnios-discuss> > >
_______________________________________________ OmniOS-discuss mailing list [email protected] http://lists.omniti.com/mailman/listinfo/omnios-discuss
