[Bug 212013] 11.0-RC1: vimage jail with pf not working
bugzilla-noreply at freebsd.org
bugzilla-noreply at freebsd.org
Sat Aug 20 14:14:52 UTC 2016
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013
Bug ID: 212013
Summary: 11.0-RC1: vimage jail with pf not working
Product: Base System
Version: 11.0-RC1
Hardware: Any
OS: Any
Status: New
Severity: Affects Many People
Priority: ---
Component: kern
Assignee: freebsd-bugs at FreeBSD.org
Reporter: qjail1 at a1poweruser.com
Tested on 11.0-RC1 with only vimage compiled into the kernel.
Tested pf in vnet jail and no firewall on host.
Tested pf in vnet jail and on the host.
Vnet jail used this /etc/devfs.rules rule
[devfsrules_vjail_pf=70]
add include $devfsrules_jail
add path pf unhide
add path pfsync unhide
add path pflog unhide
Testing no pf firewall running on host, just in vnet jail.
When starting vnet jail with pf, I check if pf kernel modules are
loaded, if not them load them. Auto loading of modules does not happen.
Issuing "ps ax" command on the host show this for pf,
925 - DL 0:00.35 [pf purge]
Issuing "ifconfig -a" command from the started vnet jail console shows
pflog0: flags=0<> metric 0 mtu 33184
groups: pflog
The pf log file is allocated but not enabled in the vnet jail.
Issuing the pf command "pfctl -sr -vv" from the started vnet jail
console show this
No ALTQ support in kernel
ALTQ related functions disabled
@0 block drop in quick on epair23b inet proto tcp from any to any port =
nicname
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0
]
[ Inserted: uid 0 pid 1301 State Creations: 0 ]
@1 pass log (all) quick on epair23b all flags S/SA keep state
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0
]
[ Inserted: uid 0 pid 1301 State Creations: 0 ]
This at lease seems to indicate pf is running in the vnet jail.
Issuing the "ping" command from the started vnet jail console works.
Issuing the "whois" command from the started vnet jail console works also,
but should not work because of the above block rule on port 43.
This indicates that the pf rules in a vnet jail are not functioning.
No pf log messages are posted in the vnet jail and no log messages
are posted in the hosts pf log.
Testing pf firewall running on host and vnet jail.
After booting host, Issuing "ps ax" command on the host show this for pf,
393 - DL 0:00.07 [pf purge]
406 - Is 0:00.01 pflogd: [priv] (pflogd)
409 - S 0:00.00 pflogd: [running] -s 116 -i pflog0 -f /var/log/pflog (pflo
Issuing "ifconfig -a" command from the started vnet jail console shows
pflog0: flags=0<> metric 0 mtu 33184
groups: pflog
The pf log file is allocated but not enabled in the vnet jail.
Issuing the pf command "pfctl -sr -vv" from the started vnet jail
console shows this
No ALTQ support in kernel
ALTQ related functions disabled
@0 block drop in quick on epair23b inet proto tcp from any to any port =
nicname
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0
]
[ Inserted: uid 0 pid 1165 State Creations: 0 ]
@1 pass log (all) quick on epair23b all flags S/SA keep state
[ Evaluations: 0 Packets: 0 Bytes: 0 States: 0
]
[ Inserted: uid 0 pid 1165 State Creations: 0 ]
Issuing the pf command "pfctl -sr -vv" from the host console shows this
No ALTQ support in kernel
ALTQ related functions disabled
@0 pass log (all) quick on fxp0 all flags S/SA keep state
[ Evaluations: 24 Packets: 9 Bytes: 740 States: 0
]
[ Inserted: uid 0 pid 411 State Creations: 3 ]
The vnet jail results are the same as above.
But the hosts pf log, logs this on vnet jail startup.
pass out on fxp0: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|icmp6]
pass out on epair23a: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|ic
pass out on fxp0: :: > ff02::1:ff00:60b: ICMP6, neighbor solicitation[|icmp6]
pass out on bridge0: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|icm
pass out on fxp0: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|icmp6]
pass out on epair23a: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|ic
pass out on bridge0: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|icm
pass out on fxp0: :: > ff02::16: HBH ICMP6, multicast listener report
v2[|icmp6]
pass out on fxp0: fe80::c1:ff:fe00:60b > ff02::16: HBH ICMP6, multicast
listener
Issuing the "ping" command from the started vnet jail console works and the
hosts pf log shows this
pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request
pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass in on bridge0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request
pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass in on bridge0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request
pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass in on bridge0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request
pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
pass in on bridge0: 8.8.8.8 > 10.23.0.2: ICMP echo reply
The hosts pf firewall is passing and logging all the traffic just as
the host firewall single rule says to do.
Issuing the "whois" command from the started vnet jail console works
and it should not work because the vnet jail pf rules says to
block all outbound traffic going to post 43. The hosts pf log shows this
pass out on fxp0: 10.23.0.2.19180 > 199.212.0.46.43:
pass in on fxp0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on bridge0: 199.212.0.46.43 > 10.23.0.2.19180:
pass out on fxp0: 10.23.0.2.19180 > 199.212.0.46.43:
pass out on fxp0: 10.23.0.2.19180 > 199.212.0.46.43:
pass in on fxp0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on bridge0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on fxp0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on bridge0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on fxp0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on bridge0: 199.212.0.46.43 > 10.23.0.2.19180:
pass out on fxp0: 10.23.0.2.19180 > 199.212.0.46.43:
pass in on fxp0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on bridge0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on fxp0: 199.212.0.46.43 > 10.23.0.2.19180:
pass in on bridge0: 199.212.0.46.43 > 10.23.0.2.19180:
Issuing the pf command "pfctl -sr -vv" from the started vnet jail
console shows that the counts have not increased. Another indicator that
the pf firewall in the vnet jail is not functioning.
Problems.
1. Why is the vnet jail issuing all that ipv6 traffic? It should only be
generated if the vnet jail interface has a ipv6 ip address coded.
2. Why is ipv4 & ipv6 traffic making it to the host and NOT showing up on
the epair23b interface?
This is a problem if the host has a few vnet jails running at same time.
IE: how am I going to control traffic on host to target correct vnet jail.
In my case I use the epair number [23] in the ip address of the vnet jail.
3. Why are the pf rules in the vnet jail not being enforced?
4. Why does pf in the vnet jail not work when pf is not run on host?
5. Why does pf in the vnet jail not log to a log file in the vnet jails
/var/log directory?
--
You are receiving this mail because:
You are the assignee for the bug.
More information about the freebsd-bugs
mailing list