[OmniOS-discuss] networking from a zone

[Jim Klimov]

27 декабря 2015 г. 4:18:40 CET, Michael Mounteney <gate03 at landcroft.co.uk> пишет:
>Hello, I tried to do this a while ago and Jim Klimov (4 Jan 2015) was
>kind enough to reply but I was unable to solve the problem with his
>advice.
>
>The problem is that DNS does not work from a non-global zone
>(hereunder referred-to as a child zone or CZ) whereas it does
>from the global zone (GZ).
>
>My IPFilter rule set is at https://pastebin.com/JYeYDPAb and it is
>the problem:  with 'svcadm disable ipfilter' I CAN do DNS from the CZ
>and with 'svcadm enable ipfilter' I CANNOT.
>
>Interface e1000g0 is connected to my cable modem (192.168.0.1) and the
>interwebs, and e1000g1 is connected to my switch and house network.
>
>The interfaces in the GZ and CZ:
>
>GZ# netstat -rn
>Routing Table: IPv4
>Destination           Gateway           Flags  Ref     Use    
>Interface 
>-------------------- -------------------- ----- ----- ----------
>--------- 
>default              192.168.0.1          UG        3    1517370       
>   
>127.0.0.1            127.0.0.1            UH        2        236 lo0   
>   
>192.168.0.0          192.168.0.9          U         3         12
>e1000g0   
>192.168.1.0          192.168.1.1          U        10   60219886
>e1000g1 
>
>(IPv6 stuff omitted for brevity)
>
>CZ# netstat -rn
>Routing Table: IPv4
>Destination           Gateway           Flags  Ref     Use    
>Interface 
>-------------------- -------------------- ----- ----- ----------
>--------- 
>default              192.168.0.1          UG        3    1517442       
>   
>127.0.0.1            127.0.0.1            UH        2         24 lo0   
>   
>192.168.0.0          192.168.0.3          U         3          3
>e1000g0   
>192.168.1.0          192.168.1.3          U         5          0
>e1000g1
>
>so the only difference is the IP addresses.
>
>Now with ipfilter disabled:
>
>CZ# nslookup www.gentoo.org
>Server:         198.142.235.14
>Address:        198.142.235.14#53
>
>Non-authoritative answer:
>www.gentoo.org  canonical name = www-bytemark-v4v6.gentoo.org.
>Name:   www-bytemark-v4v6.gentoo.org
>Address: 89.16.167.134
>
>But with it ENabled:
>
>CZ# nslookup www.gentoo.org
>;; connection timed out; no servers could be reached
>
>CZ# ping 89.16.167.134
>89.16.167.134 is alive
>
>So pinging works but DNS doesn't.
>
>Obviously, as nslookup in the CZ works with ipfilter disabled, DNS is
>configured correctly:
>
>CZ# grep '^hosts:' /etc/nsswitch.conf
>hosts:      files dns mdns
>
>CZ# cat /etc/resolv.conf
>nameserver 198.142.235.14
>nameserver 211.29.132.12
>nameserver 198.142.0.51
>
>Picking bits from Jim's responses (4 Jan 2015):
>
><< For debugging, you can 'snoop' in the zone owning the interface
>(GZ for shared, LZ for dedicated VNICs) to check what requests go
>out and what does or does not come back in. >>
>
>I tried this couldn't snoop in the CZ/LZ
>("snoop: cannot open "e1000g0": DLPI link does not exist") and a GZ
>snoop
>didn't show any DNS.
>
><< rules for e1000g0 in/out comms. name the dynamic address for the
>interface as 'e1000g0/32' which may limit to the GZ address. See if
>replacing this by the subnet /24 fixes the issue? >>
>I did this but no difference.
>
><< Does the external LZ have a fixed IP address >> Yes
>
><< you can then pluck in specific rules for its network access then? >>
>Now that e1000g0 rules in ipf.conf are all /24 this should not matter.
>
><< you start with
>  block in quick on e1000g0 from 192.168.0.0/16 to any
>which may preclude access to your router >>
>I tried removing this but no difference.
>
><< Also [...] 'ipfstat -hion' [...] 'ipmon | grep -w b' >>
>
>Tried those but couldn't see anything relevant in the output.
>
>The nub of the matter is that something in the ipf.conf is treating the
>LZ e1000g0
>interface differently from the GZ's e1000g0 but I cannot see what.
>
>Any assistance would be appreciated.

Hello again ;)

Looking at your pastebin rules, i am a bit concerned about lines 34, 42 and such with 'e1000g0/24' - this may be, possibly, limiting the ipfilter somehow to only use the GZ addresses, or those that are bound to GZ at the time of ipfilter startup, or just wholly owned by the GZ. At least I'm wary of that bit... And from route screenshots, I infer that the local zone is currently on shared stack, so its interfaces are aliased and set up from the GZ. 

If you boot up the local zone and then restart ipfilter in the GZ - does it still misbehave?

See if allowing requests from the subnet by number explicitly would help?

Also, your rules could be a bit optimized by using 'head' and 'group' to separate the int/ext interfaces in/out directions so ipfilter does not have to process the whole ruleset when you know in advance that a rule is not applicable to each and every packet ;)

As for snoop and/or libpcap cliebts not finding interfaces - 'truss' the program to see what they try to access. Maybe they want e.g. /dev/e1000g0 so you'd have to go and make symlinks:

cd /dev && ln -s ./net/* .

Some (older/vanilla) sniffer versions could also look for the base device like 'e1000' - i'm not sure how to help that...

Hope this helps,
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android