Okay, at least rolling back to Sun's IPF (Solaris 10 u4 SUNWipf[ru] plus patch 127888-07) did help - I *can* telnet from the local zone to internet, and back from outside to a NAT-published service on it, using the fake-router ARP trick.
(Concerning my comment in a previous post about problems with Linux TCP - this patch version also show'd me the same problems, at least 127889-07 on a x86 router. So there's now something broken/not integrated in the open-source variant as well.) I can also multi-home this local zone - publish the fake-router network as 192.168.151.* on e1000g1, and connect to the local servers as 192.168.155.* on e1000g0. A funny thing to note is, the IPF "rdr" rule now forwards the service regardless of which IP I publish, i.e. rdr e1000g1 0.0.0.0/0 port 80 -> 192.168.155.80 port 22 tcp and rdr e1000g1 0.0.0.0/0 port 80 -> 192.168.151.80 port 22 tcp do both work (one at a time at least ;) Another note - Ford's blog and many that follow up suggested that the global zone should plumb up a private IP used for the fake-router subnet, add a default gateway and perhaps remove the temporary IP. This is indeed required if the OS has no IPs on this network (it can't register a gateway otherwise). However, if we have a local zone with an address in this subnet, we can register the default gateway (the IP with a fake static ARP entry) and the local zone immediately inherits it. So we can use a dynamic routing program (i.e. with /etc/gateways) to maintain this route. -- Just to check up, when I try to roll back to the most original setup (global zone's internal interface e1000g0 = 192.168.155.1 is one of the default gateways, and is inherited by a local zone with only a e1000g0 alias address), networking doesn't happen: [EMAIL PROTECTED] /]# telnet 194.87.0.50 80 Trying 194.87.0.50... telnet: Unable to connect to remote host: Cannot assign requested address NAT'ed access to the Internet still works from other physical servers on 192.168.155.*, wired to e1000g0 by a switch. -- So, to summarize: 1) the fake-router trick is a viable option for multiple local zones, including the multihomed zones; it is also a bit less complex than described by the technique's author and proponents (temporary private IP in the global zone is not required); 2) exclusive IP stack is of limited value for my problem; 3) there's some regression/discrepancy between Sun IPFilter 4.1.9 variant as of patch 127888-07/127889-07, and the open-source 4.1.29. There are at least two things that work on one and not the other, and vice-versa. Darren & Co, if that's not too much to ask on my behalf - please check in the relevant changes, so there's at least one IPFilter that can do all kinds of jobs ;) 4) and we're eagerly awaiting Crossbow and other advanced features :) This message posted from opensolaris.org _______________________________________________ networking-discuss mailing list [email protected]
