From owner-freebsd-questions@freebsd.org Mon Aug 22 22:52:51 2016 Return-Path: Delivered-To: freebsd-questions@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6D09ABC2EF0; Mon, 22 Aug 2016 22:52:51 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 323681708; Mon, 22 Aug 2016 22:52:51 +0000 (UTC) (envelope-from luzar722@gmail.com) Received: by mail-it0-x22a.google.com with SMTP id x131so115501930ite.0; Mon, 22 Aug 2016 15:52:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-transfer-encoding; bh=QOOyA6SDNdsiezVcaos3IWlNjXQIoaL8I57W2ZNV+IA=; b=stjMftgAl3/tiAU38q2d/1yaam/xDaQA4JhUvyZcQGmA/YGoD3Rj4TXteVjCwK03ao z1uC6hUbywhsO3GHUje3Oc39HtG8fApeTTXrL6QtOcvgBhTsWaY2X/q6wCTFDE8iGcHZ zQrrUAfBS99lNeuPyVFYdVuGco+0F9XH9C6llZLIp4zxZGUROdDHV3aQ1cM0Etjlg4St ofIC4ua9O7mD4temjTy6UToPB4imrI3rGJOd/07sbDaDShuLhX3Q2cCtOUDQU4IzH9Km DTDQAX9Ep+Bvsd2RKOg+pinuEII0M6UdB1LqDtraV5RB5Nr8p43sE6O327V+ZMXbLt8A gXBA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-transfer-encoding; bh=QOOyA6SDNdsiezVcaos3IWlNjXQIoaL8I57W2ZNV+IA=; b=jZ35gGReHJu6qJFtkdkldOk25dxm8y9rjILhh8UCvZfxR32XJixdGUZ9WmZPgaCS5M VDuy6GqvtmqUHlr0h/l2xUcn1J6wA97q61r8CObxEb342r1Xfx14G04IPlda6U/N4RYK Op58vLICNqaPDz5XxfrBFL+EgHwkMwIcEY+1O93c2zsTLgLTstd82CZ/aoWDjRPqhxt+ 91x3nP4xD29r1/n4M0Bh1VU4EZoE2+81E274OwyWp02FGMpUZpbby5+DsMw8yzPrRk81 QHHUe9oG1oRJWIuXQ+ubJcJ0bsWg+68oXmWny/7NHWqC8nXR0EhIyLgica3vNk0QeEBs 7DsQ== X-Gm-Message-State: AEkoouvnJCTHnQYjvEBIgIse4xFjIdckRX1JEsS5efUoRGKNwOOTaHawiKOMt4QM8GGXng== X-Received: by 10.36.225.9 with SMTP id n9mr23319514ith.30.1471906370380; Mon, 22 Aug 2016 15:52:50 -0700 (PDT) Received: from [10.0.10.3] (cpe-24-165-196-54.neo.res.rr.com. [24.165.196.54]) by smtp.googlemail.com with ESMTPSA id o74sm346867ioe.37.2016.08.22.15.52.48 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 15:52:49 -0700 (PDT) Message-ID: <57BB8247.6060907@gmail.com> Date: Mon, 22 Aug 2016 18:52:55 -0400 From: Ernie Luzar User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Freebsd Questions CC: "freebsd-jail@freebsd.org" Subject: Problem 11.0-RC1 vnet jails with ipfilter References: <57B1E1BC.4090205@gmail.com> <078403E1-D8A3-4E52-B218-7A8B4400749A@lists.zabbadoz.net> <57B375C6.9030500@gmail.com> <89E52542-8E6B-4BA6-921E-E939A3F3A038@lists.zabbadoz.net> <57B3B858.4000707@gmail.com> <20160817072244.GO18643@e-new.0x20.net> In-Reply-To: <20160817072244.GO18643@e-new.0x20.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2016 22:52:51 -0000 Hello List. I have a working setup where I am running IPF on the host and in a vnet jail at the same time. The problem is I don't think the vnet IPF rules are being enforced. To verify the vnet IPF rules are active and being enforced, I have a rule to deny outbound for port 43. Port 43 is used by the "whois" command. When I issue the "whois" command from the vnet jail console, I get whois results when it should not function. I may have overlooked something or my testing concept may be faulty, so I am requesting some other eyes to review what I am doing for a reason I am getting the results I am getting. I have run the test using a vimage kernel and a vimage/ipf kernel and get the same results. The vnet jail is using this /etc/devfs.rules rule [devfsrules_vjail_ipf=60] add include $devfsrules_jail add path ipl unhide add path ipl0 unhide add path ipf unhide add path ipauth unhide add path ipnat unhide add path ipstate unhide # used by ipstate #add path kmem unhide #add path kernel unhide and yes the "devfs rule showsets" command does show rule number 60. Issuing the ipfilter command "ipfstat -hnoi" from the host console shows these rules 0 @1 pass out quick on lo0 all 0 @2 pass out log quick on fxp0 all 0 @1 pass in quick on lo0 all 1 @2 pass in log quick on fxp0 all Issuing the ipfilter command "ipfstat -hnoi" from the started vnet jail console shows these rules 0 @1 pass out quick on lo0 all 0 @2 block out log quick on epair17b proto tcp from any to any port = nicname 0 @3 pass out log quick on epair17b all 0 @1 pass in quick on lo0 all 0 @2 pass in log quick on epair17b all There are 0 counts because the ipstate command is restricted from accessing kmem & kernel from inside of the vnet jail. But this at lease seems to indicate ipfilter is running in the vnet jail. Issuing the "ping" command from the started vnet jail console works and the hosts ipfilter log shows this [sniped to fit] fxp0 @0:2 p 10.11.0.2 -> 8.8.8.8 PR icmp len 20 84 icmp echo/0 OUT fxp0 @0:2 p 8.8.8.8 -> 10.11.0.2 PR icmp len 20 84 icmp echoreply/0 IN fxp0 @0:2 p 10.11.0.2 -> 8.8.8.8 PR icmp len 20 84 icmp echo/0 OUT fxp0 @0:2 p 8.8.8.8 -> 10.11.0.2 PR icmp len 20 84 icmp echoreply/0 IN fxp0 @0:2 p 10.11.0.2 -> 8.8.8.8 PR icmp len 20 84 icmp echo/0 OUT fxp0 @0:2 p 8.8.8.8 -> 10.11.0.2 PR icmp len 20 84 icmp echoreply/0 IN fxp0 @0:2 p 10.11.0.2 -> 8.8.8.8 PR icmp len 20 84 icmp echo/0 OUT fxp0 @0:2 p 8.8.8.8 -> 10.11.0.2 PR icmp len 20 84 icmp echoreply/0 IN Issuing the "whois" command from the started vnet jail console works also, but should not work because of the block rule on port 43. The hosts ipfilter log shows this [sniped to fit] fxp0 @0:2 p 10.2.0.2,51575 -> 192.0.32.59,43 PR tcp len 20 60 -S OUT fxp0 @0:2 p 192.0.32.59,43 -> 10.2.0.2,51575 PR tcp len 20 60 -AS IN fxp0 @0:2 p 10.2.0.2,51575 -> 192.0.32.59,43 PR tcp len 20 52 -A OUT fxp0 @0:2 p 10.2.0.2,51575 -> 192.0.32.59,43 PR tcp len 20 61 -AP OUT fxp0 @0:2 p 192.0.32.59,43 -> 10.2.0.2,51575 PR tcp len 20 52 -A IN fxp0 @0:2 p 192.0.32.59,43 -> 10.2.0.2,51575 PR tcp len 20 367 -AP IN fxp0 @0:2 p 192.0.32.59,43 -> 10.2.0.2,51575 PR tcp len 20 52 -AF IN fxp0 @0:2 p 10.2.0.2,51575 -> 192.0.32.59,43 PR tcp len 20 52 -A OUT fxp0 @0:2 p 10.2.0.2,51575 -> 192.0.32.59,43 PR tcp len 20 52 -AF OUT fxp0 @0:2 p 10.2.0.2,51903 -> 199.71.0.46,43 PR tcp len 20 60 -S OUT fxp0 @0:2 p 192.0.32.59,43 -> 10.2.0.2,51575 PR tcp len 20 52 -A IN fxp0 @0:2 p 199.71.0.46,43 -> 10.2.0.2,51903 PR tcp len 20 60 -AS IN fxp0 @0:2 p 10.2.0.2,51903 -> 199.71.0.46,43 PR tcp len 20 52 -A OUT fxp0 @0:2 p 10.2.0.2,51903 -> 199.71.0.46,43 PR tcp len 20 63 -AP OUT fxp0 @0:2 p 199.71.0.46,43 -> 10.2.0.2,51903 PR tcp len 20 52 -A IN fxp0 @0:2 p 199.71.0.46,43 -> 10.2.0.2,51903 PR tcp len 20 293 -AP IN fxp0 @0:2 p 199.71.0.46,43 -> 10.2.0.2,51903 PR tcp len 20 1500 -A IN I would think that this indicates that the ipfilter rules in a vnet jail are not functioning. I can start the vnet jail without any firewall running in it and get the same results. Thanks for your help.