Summary: | 11.0-RC1: vimage jail with ipfilter not working | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | Joe Barbish <qjail1> | ||||
Component: | kern | Assignee: | Cy Schubert <cy> | ||||
Status: | Closed FIXED | ||||||
Severity: | Affects Only Me | CC: | cy, emaste | ||||
Priority: | --- | ||||||
Version: | 11.0-RC1 | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
Joe Barbish
2016-08-19 17:19:54 UTC
12.0-RC1 and still have this problem. I've set up an environment like yours on my testbed. Confirmed the problem exists locally. This is the network setup test system config I used to verify the 11.0-RC1 reported bug still exists in 12.0-RC1. Its good to know you confirmed it. This is configuration of my test system. It's running 12.0-RC1 i386 and is on LAN behind my production gateway host which is running 11.2 amd64 with ipf firewall. Just reran this test configuration on the test system. NO firewall on test system host. kldload ipl.ko from host console. Vnet jail using bridge/epair with ipf configured using normal parameters in vnet jail's rc.conf. "Local0 /var/log/ipf.log" line in vnet jails /etc/syslog.conf to allow ipf logging. Using same /etc/devfs.rules file as posted previously. Rules file contains only 2 lines block out log quick all pass in log all From the vnet jail console "ipfstat -hnoi" shows the 2 rules with zero count. Then issue ping -c2 8.8.8.8 and receive the normal reply that all packets returned. "ipfstat -hnoi" shows the 2 rules still have zero count. If ipf running in the vnet jail was functional, the ping would have been blocked and logged which did not happen. It's important that ipf logging populate it's log file in the vnet jail ipf is running in. Thanks for working on this bug. No problem. Your setup is similar to mine. My testbed has an unused interface to my DMZ for this purpose. Rather than port 43 I verified using port 22 to my prod firewall in the DMZ. I suspect a global variable wasn't converted to V_ in 2016 by r302298 & friends. Logging is another thing that needs to be looked at. Created attachment 204898 [details]
ipfilter vnet enabler
This patch should address your issue. Can you give it a spin?
A commit references this bug: Author: cy Date: Wed Jun 12 11:06:55 UTC 2019 New revision: 348986 URL: https://svnweb.freebsd.org/changeset/base/348986 Log: Register pfil hooks when VNET != vnet0. r302298, which virtualized ipf, assumed the pfil hook registration performed in ipf_modload() would take care of this. However ipf_modload() is only called when the ipl kld is loaded or when ipfilter is first called when it is statically linked into the kernel at build time. Prior to this, even though r302298 has been in the tree for a while, it has never been used. So, r302298 in reality begins now. PR: 212000 Reported by: ahsanb@ MFC after: 1 month Changes: head/sys/contrib/ipfilter/netinet/mlfk_ipl.c Fixed. A commit references this bug: Author: cy Date: Fri Jul 12 00:35:44 UTC 2019 New revision: 349926 URL: https://svnweb.freebsd.org/changeset/base/349926 Log: MFC r348986: Register pfil hooks when VNET != vnet0. r302298, which virtualized ipf, assumed the pfil hook registration performed in ipf_modload() would take are of this. However ipf_modload() is only called when the ipl kld is loaded or when ipfilter is first called when it is statically linked into the kernel at build time. Prior to this, even though r302298 has been in the tree for a while, it has never been used. So, r302298 in reality begins now. PR: 212000 Reported by: ahsanb@ Changes: _U stable/12/ stable/12/sys/contrib/ipfilter/netinet/mlfk_ipl.c |