Discussion:
vnet jail with ipfw having logging problem
Joe
2013-05-01 00:16:59 UTC
Permalink
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using
the jail(8) definition statements for starting and stopping the vnet
jail. As a side note non-vnet jails are working as expected.

The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
options IPFIREWALL_FORWARD

compiled in.


The host is also running ipfw from its rc.conf file.

Both the vnet jail and the host, have ipfw rules, for logging everything.

Host
ipfw -q add 010 allow all from any to any via lo0
ipfw -q add 010 allow log all from any to any via rl0


vnet jail
# pass the vnet epairXb to the jail rule.
if [ -e /etc/epair ]; then
pif=`cat "/etc/epair"`
else
pif="lo0"
fi
ipfw -q add 010 allow all from any to any via lo0
ipfw -q add 010 allow log all from any to any via $pif

I work around the (nojail keyword problem with the rc.d startup scripts)
by manually issuing service netif start, service routing start, service
ipfw start commands, after the exec.start="/bin/sh /etc/rc" is run and
issue them in reverse order before the
exec.stop="/bin/sh /etc/rc.shutdown" is executed.

After booting the system I can ping the internet from the host and see
the rule counter increase using this command "ipfw -a list". I also see
the ping packets logged in the hosts /var/log/security file.

After the vnet jail is started I see a empty /var/log/security file
inside of the vnet jail that never gets populated.

But in the hosts /var/log/security file I see log messages from the
vnet jail. I would expect to see the vnet jail log message interspersed
with the host logging messages as the jails packets pass through the
hosts ipfw firewall.

But I only see the vnet jails ipfw logging messages in the hosts
/var/log/security file from that point on.

I can stop the vnet jail and restart it and the ipfw logged messages
continue to populate the hosts security file.

With the vnet jail stopped, I issue ping from host to internet and get
100% packets replied message. The ipfw -a list command from the host
shows the rule count has increased, but there are no host packets logged
to the hosts security file.

Rebooting the host is the only way to get the host to log ipfw packets
and this only works until the vent jail starts after which time the host
no longer logs packets.

I can comment out the firewall statements in the hosts rc.conf and
reboot the host without ipfw, but since ipfw is compiled into the kernel
ipfw is really running on the host with the allow all default and the
started vmet/ipfw jail still populates the hosts security file.

I'm thinking this is a bug.

I would like conformation of this problem.

Or maybe someone has some other (nojail keyword work around method) that
results in the vnet/ipfw jail logging to the jails security file and the
hosts ipfw logging to it's security file that they would share with me.


Thanks
Joe
Ian Smith
2013-05-01 16:30:19 UTC
Permalink
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using the
jail(8) definition statements for starting and stopping the vnet jail. As a
side note non-vnet jails are working as expected.
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously
low limit on logging? Otherwise, after e.g. just 5 pings and 5 ping
responses are logged, all logging ceases until issuing 'ipfw resetlog'.
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
options IPFIREWALL_FORWARD
compiled in.
Ian
Joe
2013-05-01 21:43:03 UTC
Permalink
Post by Ian Smith
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using the
jail(8) definition statements for starting and stopping the vnet jail. As a
side note non-vnet jails are working as expected.
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously
low limit on logging? Otherwise, after e.g. just 5 pings and 5 ping
responses are logged, all logging ceases until issuing 'ipfw resetlog'.
/usr/src/sys/conf/NOTES says IPFIREWALL_VERBOSE_LIMIT; limits the number
of times a matching entry can be logged. Says nothing about this limit
being the maximum number of log records allowed after which the log file
is closed for business. Are you saying the /usr/src/sys/conf/NOTES info
is no longer true?

Without IPFIREWALL_VERBOSE and IPFIREWALL_VERBOSE_LIMIT where does the
logged packets get written to? /var/log/security

I have not used ipfw since it's ipfw2 rewrite so my knowledge is dated.
Post by Ian Smith
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
I kept getting kernel compile errors using "options IPFIREWALL_NAT". I
thought the error was caused by vimage. Now I know "options LIBALIAS" is
required. Could not find info on internet search for IPFIREWALL_NAT with
vimage kernel.

Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail or having logging work on the host and within the vnet jail?
Nikos Vassiliadis
2013-05-01 22:15:13 UTC
Permalink
Post by Joe
Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail
ipfw nat should work in a vnet jail.

HTH, Nikos
Ian Smith
2013-05-02 05:42:00 UTC
Permalink
Post by Joe
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using
the
Post by Joe
jail(8) definition statements for starting and stopping the vnet jail.
As a
Post by Joe
side note non-vnet jails are working as expected.
Post by Joe
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously low
limit on logging? Otherwise, after e.g. just 5 pings and 5 ping responses
are logged, all logging ceases until issuing 'ipfw resetlog'.
/usr/src/sys/conf/NOTES says IPFIREWALL_VERBOSE_LIMIT; limits the number of
times a matching entry can be logged. Says nothing about this limit being the
maximum number of log records allowed after which the log file is closed for
business. Are you saying the /usr/src/sys/conf/NOTES info is no longer true?
You showed one (1) 'log' rule for each of the host's and jail's ruleset.
Once that one rule has been logged 'logamount' times (default as per
NOTES is 100, but in your case is 10) then logging for THAT rule stops,
therefore with only one 'log' rule, ALL logging stops. Understand?

If you take the time to properly study the correct reference, ipfw(8),
all of this will become clear. See especially section SYSCTL VARIABLES,
and read thoroughly 'log [logamount number]', at the very least. Ignore
the Handbook section on ipfw, it's full of errors and misunderstandings.
Without IPFIREWALL_VERBOSE and IPFIREWALL_VERBOSE_LIMIT where does the logged
packets get written to? /var/log/security
See above. Both of these options merely set defaults for the sysctls.
I have not used ipfw since it's ipfw2 rewrite so my knowledge is dated.
Indeed it is; that's a very long time ago.
Post by Joe
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
I kept getting kernel compile errors using "options IPFIREWALL_NAT". I
thought the error was caused by vimage. Now I know "options LIBALIAS" is
required. Could not find info on internet search for IPFIREWALL_NAT with
vimage kernel.
Apart from FIREWALL_FORWARD (not even that in 10.x), none of that needs
to be in the kernel, it's all loadable as modules; see /etc/rc.d/ipfw.

If you're doing NAT in the vimage jail, you must have at least two
interfaces assigned to the jail. Care to show your config for that?
Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail or having logging work on the host and within the vnet jail?
No, but I have just on 15 years experience managing ipfw firewalls :)

Ian
Anders Hagman
2013-05-02 10:09:08 UTC
Permalink
Hi
Post by Ian Smith
Post by Joe
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using
the
Post by Joe
jail(8) definition statements for starting and stopping the vnet jail.
As a
Post by Joe
side note non-vnet jails are working as expected.
Post by Joe
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously low
limit on logging? Otherwise, after e.g. just 5 pings and 5 ping responses
are logged, all logging ceases until issuing 'ipfw resetlog'.
/usr/src/sys/conf/NOTES says IPFIREWALL_VERBOSE_LIMIT; limits the number of
times a matching entry can be logged. Says nothing about this limit being the
maximum number of log records allowed after which the log file is closed for
business. Are you saying the /usr/src/sys/conf/NOTES info is no longer true?
You showed one (1) 'log' rule for each of the host's and jail's ruleset.
Once that one rule has been logged 'logamount' times (default as per
NOTES is 100, but in your case is 10) then logging for THAT rule stops,
therefore with only one 'log' rule, ALL logging stops. Understand?
If you take the time to properly study the correct reference, ipfw(8),
all of this will become clear. See especially section SYSCTL VARIABLES,
and read thoroughly 'log [logamount number]', at the very least. Ignore
the Handbook section on ipfw, it's full of errors and misunderstandings.
Without IPFIREWALL_VERBOSE and IPFIREWALL_VERBOSE_LIMIT where does the logged
packets get written to? /var/log/security
See above. Both of these options merely set defaults for the sysctls.
I have not used ipfw since it's ipfw2 rewrite so my knowledge is dated.
Indeed it is; that's a very long time ago.
Post by Joe
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
I kept getting kernel compile errors using "options IPFIREWALL_NAT". I
thought the error was caused by vimage. Now I know "options LIBALIAS" is
required. Could not find info on internet search for IPFIREWALL_NAT with
vimage kernel.
Apart from FIREWALL_FORWARD (not even that in 10.x), none of that needs
to be in the kernel, it's all loadable as modules; see /etc/rc.d/ipfw.
If you're doing NAT in the vimage jail, you must have at least two
interfaces assigned to the jail. Care to show your config for that?
Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail or having logging work on the host and within the vnet jail?
No, but I have just on 15 years experience managing ipfw firewalls :)
When you are new at things you do mistakes, remember.

To try to answer Joes question:

You don't need to compile anything into the kernel regarding ipfw.

Just load the ipfw module in the host system with:

kldload ipfw

By default a deny all rule is added, so add a allow rule to the host system.

ipfw add 10 allow ip from any to any

To log things you change the sysctl value net.inet.ip.fw.verbose to 1

sysctl net.inet.ip.fw.verbose=1

If you keep net.inet.ip.fw.verbose_limit=0 you don't have a log limit, and for tests thats fine.

log in to the jail system. Change the sysctl value net.inet.ip.fw.verbose to 1

sysctl net.inet.ip.fw.verbose=1

Add a logging firewall rule

ipfw add 10 allow log ip from any to any

Do a ping to an external system.
Look inside /var/log/security in the jail system and its empty.
Go to the main host and look at the /var/log/security file and you will find log entries.

I can confirm Joes bug. I don't have a log rule in the main host but still get log messages.
All log messages are from the log rule in the jail system.

System used: 9.1-RELEASE-p2

BR
/Anders
Joe
2013-05-02 13:49:43 UTC
Permalink
Post by Anders Hagman
Hi
Post by Ian Smith
Post by Joe
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using
the
Post by Joe
jail(8) definition statements for starting and stopping the vnet jail.
As a
Post by Joe
side note non-vnet jails are working as expected.
Post by Joe
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously low
limit on logging? Otherwise, after e.g. just 5 pings and 5 ping responses
are logged, all logging ceases until issuing 'ipfw resetlog'.
/usr/src/sys/conf/NOTES says IPFIREWALL_VERBOSE_LIMIT; limits the number of
times a matching entry can be logged. Says nothing about this limit being the
maximum number of log records allowed after which the log file is closed for
business. Are you saying the /usr/src/sys/conf/NOTES info is no longer true?
You showed one (1) 'log' rule for each of the host's and jail's ruleset.
Once that one rule has been logged 'logamount' times (default as per
NOTES is 100, but in your case is 10) then logging for THAT rule stops,
therefore with only one 'log' rule, ALL logging stops. Understand?
If you take the time to properly study the correct reference, ipfw(8),
all of this will become clear. See especially section SYSCTL VARIABLES,
and read thoroughly 'log [logamount number]', at the very least. Ignore
the Handbook section on ipfw, it's full of errors and misunderstandings.
Without IPFIREWALL_VERBOSE and IPFIREWALL_VERBOSE_LIMIT where does the logged
packets get written to? /var/log/security
See above. Both of these options merely set defaults for the sysctls.
I have not used ipfw since it's ipfw2 rewrite so my knowledge is dated.
Indeed it is; that's a very long time ago.
Post by Joe
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
I kept getting kernel compile errors using "options IPFIREWALL_NAT". I
thought the error was caused by vimage. Now I know "options LIBALIAS" is
required. Could not find info on internet search for IPFIREWALL_NAT with
vimage kernel.
Apart from FIREWALL_FORWARD (not even that in 10.x), none of that needs
to be in the kernel, it's all loadable as modules; see /etc/rc.d/ipfw.
If you're doing NAT in the vimage jail, you must have at least two
interfaces assigned to the jail. Care to show your config for that?
Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail or having logging work on the host and within the vnet jail?
No, but I have just on 15 years experience managing ipfw firewalls :)
When you are new at things you do mistakes, remember.
You don't need to compile anything into the kernel regarding ipfw.
kldload ipfw
By default a deny all rule is added, so add a allow rule to the host system.
ipfw add 10 allow ip from any to any
To log things you change the sysctl value net.inet.ip.fw.verbose to 1
sysctl net.inet.ip.fw.verbose=1
If you keep net.inet.ip.fw.verbose_limit=0 you don't have a log limit, and for tests thats fine.
log in to the jail system. Change the sysctl value net.inet.ip.fw.verbose to 1
sysctl net.inet.ip.fw.verbose=1
Add a logging firewall rule
ipfw add 10 allow log ip from any to any
Do a ping to an external system.
Look inside /var/log/security in the jail system and its empty.
Go to the main host and look at the /var/log/security file and you will find log entries.
I can confirm Joes bug. I don't have a log rule in the main host but still get log messages.
All log messages are from the log rule in the jail system.
System used: 9.1-RELEASE-p2
BR
/Anders
Thank you Anders, your reply was direct and to the point.

Lets talk about this bug. The console.log parameter creates a log file
in the hosts /var/log directory for each jail. I would think the ipfw
log file should behave the same way. IE: the host ipfw log should be
going to the hosts /var/log/security file with each ipfw jail creating
it's own /var/log/jailname.security file on the host and not create a
/var/log/security file in the jails filesystem. I searched the PR
database for any PR's with vnet or vimage and ipfw logging and came up
with no hits. Should I submit a PR about this problem?

I tested doing a kldload ipfw and fall into the default deny problem.
Is there a sysctl to flip the default deny to default accept?

Thanks
Joe
Mark Felder
2013-05-02 14:29:58 UTC
Permalink
Post by Joe
I tested doing a kldload ipfw and fall into the default deny problem.
Is there a sysctl to flip the default deny to default accept?
options IPFIREWALL_DEFAULT_TO_ACCEPT when you build the kernel is the only
way AFAIK
Ian Smith
2013-05-02 14:59:38 UTC
Permalink
Post by Mark Felder
Post by Joe
I tested doing a kldload ipfw and fall into the default deny problem.
Is there a sysctl to flip the default deny to default accept?
options IPFIREWALL_DEFAULT_TO_ACCEPT when you build the kernel is the only
way AFAIK
% man ipfw
/FINE POINTS
[..]
o If you are logged in over a network, loading the kld(4) version of
ipfw is probably not as straightforward as you would think. The fol-
lowing command line is recommended:

kldload ipfw && \
ipfw add 32000 allow ip from any to any

Along the same lines, doing an

ipfw flush

in similar surroundings is also a bad idea.

I expect running jexec(8) qualifies as 'logged in over a network' here?

cheers, Ian
Ian Smith
2013-05-02 16:46:10 UTC
Permalink
Post by Anders Hagman
Hi
Yo
Post by Anders Hagman
Post by Ian Smith
Post by Joe
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using
the
Post by Joe
jail(8) definition statements for starting and stopping the vnet jail.
As a
Post by Joe
side note non-vnet jails are working as expected.
Post by Joe
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously low
limit on logging? Otherwise, after e.g. just 5 pings and 5 ping responses
are logged, all logging ceases until issuing 'ipfw resetlog'.
/usr/src/sys/conf/NOTES says IPFIREWALL_VERBOSE_LIMIT; limits the number of
times a matching entry can be logged. Says nothing about this limit being the
maximum number of log records allowed after which the log file is closed for
business. Are you saying the /usr/src/sys/conf/NOTES info is no longer true?
You showed one (1) 'log' rule for each of the host's and jail's ruleset.
Once that one rule has been logged 'logamount' times (default as per
NOTES is 100, but in your case is 10) then logging for THAT rule stops,
therefore with only one 'log' rule, ALL logging stops. Understand?
If you take the time to properly study the correct reference, ipfw(8),
all of this will become clear. See especially section SYSCTL VARIABLES,
and read thoroughly 'log [logamount number]', at the very least. Ignore
the Handbook section on ipfw, it's full of errors and misunderstandings.
Without IPFIREWALL_VERBOSE and IPFIREWALL_VERBOSE_LIMIT where does the logged
packets get written to? /var/log/security
See above. Both of these options merely set defaults for the sysctls.
I have not used ipfw since it's ipfw2 rewrite so my knowledge is dated.
Indeed it is; that's a very long time ago.
Post by Joe
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
I kept getting kernel compile errors using "options IPFIREWALL_NAT". I
thought the error was caused by vimage. Now I know "options LIBALIAS" is
required. Could not find info on internet search for IPFIREWALL_NAT with
vimage kernel.
Apart from FIREWALL_FORWARD (not even that in 10.x), none of that needs
to be in the kernel, it's all loadable as modules; see /etc/rc.d/ipfw.
If you're doing NAT in the vimage jail, you must have at least two
interfaces assigned to the jail. Care to show your config for that?
Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail or having logging work on the host and within the vnet jail?
No, but I have just on 15 years experience managing ipfw firewalls :)
When you are new at things you do mistakes, remember.
I still do mistakes. Trying to teach fishing rather than just tossing
another fish is often one of mine :) I'm glad you had some to spare.
Post by Anders Hagman
You don't need to compile anything into the kernel regarding ipfw.
kldload ipfw
By default a deny all rule is added, so add a allow rule to the host system.
ipfw add 10 allow ip from any to any
To log things you change the sysctl value net.inet.ip.fw.verbose to 1
sysctl net.inet.ip.fw.verbose=1
If you keep net.inet.ip.fw.verbose_limit=0 you don't have a log limit, and for tests thats fine.
Sure, though the default of 100 is plenty for such tests; it's
surprisingly easy to DoS syslogd with e.g. a logged flood ping ..
Post by Anders Hagman
log in to the jail system. Change the sysctl value net.inet.ip.fw.verbose to 1
sysctl net.inet.ip.fw.verbose=1
Add a logging firewall rule
ipfw add 10 allow log ip from any to any
Do a ping to an external system.
Look inside /var/log/security in the jail system and its empty.
But it does exist, rw for root, with 0 or more bytes, right? And does
the vimage jail's /etc/syslog.conf contain:
security.* /var/log/security

That is, I'm checking that the jail's syslogd should be handling these.
What happens if you run in the jail, say:
# logger -p security.info Syslog, wherefore art thou, Syslog?
Does that go to the jail's /var/log/security? or the host's?
Post by Anders Hagman
Go to the main host and look at the /var/log/security file and you will find log entries.
Showing the host's hostname, or the jail's? Can you post some examples?
Post by Anders Hagman
I can confirm Joes bug. I don't have a log rule in the main host but still get log messages.
All log messages are from the log rule in the jail system.
System used: 9.1-RELEASE-p2
BR
/Anders
Ok, before determining that this is an ipfw-only issue - in which case
we need to move it over to freebsd-ipfw@ - can you confirm that normal
syslogging in the jail to /var/log/messages and such is working?

In particular I'm wondering what happens when you do set (say)
net.inet.ip.fw.verbose_limit=10 and then ping from the jail until
logging stops .. you should then see a message such as

Apr 23 23:42:05 sola kernel: ipfw: limit 500 reached on entry 26400

both in /var/log/security and in /var/log/messages since it's logged
as security.notice and default syslog.conf is for *.notice to log to
/var/log/messages .. see the tail of /sys/netpfil/ipfw/ip_fw_log.c

Yes sure, I'm flying blind, don't have a system with jails here yet, and
am making assumptions about how syslogd(8) should work in jails that I
really don't have time to properly research currently, nor am I properly
across all the security implications of (particularly vimage) jails.

cheers, Ian
Anders Hagman
2013-05-02 20:05:49 UTC
Permalink
Post by Ian Smith
Post by Anders Hagman
Hi
Yo
Post by Anders Hagman
Post by Ian Smith
Post by Joe
I have ipfw running inside of a vnet jail on a 9.1-RELEASE host using
the
Post by Joe
jail(8) definition statements for starting and stopping the vnet jail.
As a
Post by Joe
side note non-vnet jails are working as expected.
Post by Joe
The host is running a custom kernel with modules and with
options VIMAGE
nooptions SCTP
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=10
What steps have you taken during testing to override this ridiculously low
limit on logging? Otherwise, after e.g. just 5 pings and 5 ping responses
are logged, all logging ceases until issuing 'ipfw resetlog'.
/usr/src/sys/conf/NOTES says IPFIREWALL_VERBOSE_LIMIT; limits the number of
times a matching entry can be logged. Says nothing about this limit being the
maximum number of log records allowed after which the log file is closed for
business. Are you saying the /usr/src/sys/conf/NOTES info is no longer true?
You showed one (1) 'log' rule for each of the host's and jail's ruleset.
Once that one rule has been logged 'logamount' times (default as per
NOTES is 100, but in your case is 10) then logging for THAT rule stops,
therefore with only one 'log' rule, ALL logging stops. Understand?
If you take the time to properly study the correct reference, ipfw(8),
all of this will become clear. See especially section SYSCTL VARIABLES,
and read thoroughly 'log [logamount number]', at the very least. Ignore
the Handbook section on ipfw, it's full of errors and misunderstandings.
Without IPFIREWALL_VERBOSE and IPFIREWALL_VERBOSE_LIMIT where does the logged
packets get written to? /var/log/security
See above. Both of these options merely set defaults for the sysctls.
I have not used ipfw since it's ipfw2 rewrite so my knowledge is dated.
Indeed it is; that's a very long time ago.
Post by Joe
options IPFIREWALL_DEFAULT_TO_ACCEPT
options IPFIREWALL_IPDIVERT
You'd likely do better using in-kernel NAT; natd doesn't get much love.
I kept getting kernel compile errors using "options IPFIREWALL_NAT". I
thought the error was caused by vimage. Now I know "options LIBALIAS" is
required. Could not find info on internet search for IPFIREWALL_NAT with
vimage kernel.
Apart from FIREWALL_FORWARD (not even that in 10.x), none of that needs
to be in the kernel, it's all loadable as modules; see /etc/rc.d/ipfw.
If you're doing NAT in the vimage jail, you must have at least two
interfaces assigned to the jail. Care to show your config for that?
Do you have first hand experience getting "ipfw kernel nat" to work in a
vimage jail or having logging work on the host and within the vnet jail?
No, but I have just on 15 years experience managing ipfw firewalls :)
When you are new at things you do mistakes, remember.
I still do mistakes. Trying to teach fishing rather than just tossing
another fish is often one of mine :) I'm glad you had some to spare.
I know the game. ;->
Post by Ian Smith
Post by Anders Hagman
You don't need to compile anything into the kernel regarding ipfw.
kldload ipfw
By default a deny all rule is added, so add a allow rule to the host system.
ipfw add 10 allow ip from any to any
To log things you change the sysctl value net.inet.ip.fw.verbose to 1
sysctl net.inet.ip.fw.verbose=1
If you keep net.inet.ip.fw.verbose_limit=0 you don't have a log limit, and for tests thats fine.
Sure, though the default of 100 is plenty for such tests; it's
surprisingly easy to DoS syslogd with e.g. a logged flood ping ..
Post by Anders Hagman
log in to the jail system. Change the sysctl value net.inet.ip.fw.verbose to 1
sysctl net.inet.ip.fw.verbose=1
Add a logging firewall rule
ipfw add 10 allow log ip from any to any
Do a ping to an external system.
Look inside /var/log/security in the jail system and its empty.
But it does exist, rw for root, with 0 or more bytes, right? And does
security.* /var/log/security
Yes
Post by Ian Smith
That is, I'm checking that the jail's syslogd should be handling these.
# logger -p security.info Syslog, wherefore art thou, Syslog?
Does that go to the jail's /var/log/security? or the host's?
In jail system webben:
logger -p security.info Syslog, wherefore art thou, Syslog?

tail /var/log/security
May 2 21:24:48 webben root: Syslog, wherefore art thou, Syslog?
Post by Ian Smith
Post by Anders Hagman
Go to the main host and look at the /var/log/security file and you will find log entries.
Showing the host's hostname, or the jail's? Can you post some examples?
In host system dator5:
tail /var/log/security
May 2 21:29:15 dator5 kernel: ipfw: 10 Accept TCP 10.2.0.101:80 94.153.64.32:3085 out via vlan101
May 2 21:29:15 dator5 kernel: ipfw: 10 Accept TCP 94.153.64.32:3085 10.2.0.101:80 in via vlan101
Post by Ian Smith
Post by Anders Hagman
I can confirm Joes bug. I don't have a log rule in the main host but still get log messages.
All log messages are from the log rule in the jail system.
System used: 9.1-RELEASE-p2
BR
/Anders
Ok, before determining that this is an ipfw-only issue - in which case
syslogging in the jail to /var/log/messages and such is working?
In jail system
login anders
password *****

tail /var/log/messages
May 2 21:41:57 webben login: login_getclass: unknown class 'svensk'
May 2 21:42:00 webben last message repeated 3 times
Post by Ian Smith
In particular I'm wondering what happens when you do set (say)
net.inet.ip.fw.verbose_limit=10 and then ping from the jail until
logging stops .. you should then see a message such as
Apr 23 23:42:05 sola kernel: ipfw: limit 500 reached on entry 26400
both in /var/log/security and in /var/log/messages since it's logged
as security.notice and default syslog.conf is for *.notice to log to
/var/log/messages .. see the tail of /sys/netpfil/ipfw/ip_fw_log.c
Yes sure, I'm flying blind, don't have a system with jails here yet, and
am making assumptions about how syslogd(8) should work in jails that I
really don't have time to properly research currently, nor am I properly
across all the security implications of (particularly vimage) jails.
On jail system:

sysctl net.inet.ip.fw.verbose_limit=10

Pinging repeatedly. Just continue to log to host system.

Add new ipfw log role will use the new limit:

ipfw add 5 allow log ip from any to any
00005 allow log logamount 10 ip from any to any

New ping test.
/var/log/security in host system :

May 2 21:52:28 dator5 kernel: ipfw: 5 Accept ICMP:8.0 10.2.0.101 195.49.241.132 out via vlan101
May 2 21:52:28 dator5 kernel: ipfw: 5 Accept ICMP:0.0 195.49.241.132 10.2.0.101 in via vlan101
May 2 21:52:28 dator5 kernel: ipfw: limit 10 reached on entry 5

/var/log/messages in host system :

May 2 21:52:28 dator5 kernel: ipfw: limit 10 reached on entry 5

Nothing at all is logged to the jail syslog.

BR
/Anders
Joe
2013-05-03 00:54:33 UTC
Permalink
I am posting 2 console logs created using the script command.

The main differences between the 2 is,
log 1 is a 9.1 kernel with modules and vimage compiled in. This shows
the first problem being that dynamically loaded ipfw with a vimage
kernel don't work.

Log 2 is a 9.1 kernel with modules and vimage plus ipfw compiled in.
This shows the second problem with vnet jails running ipfw log to host
security file and don't log any ipfw log messages to the hosts message
file. Secondly the vnet jails security and messages files never get
populated with ipfw log messages.

Console log 1.
9.1-RELEASE ipfw dynamically loaded by firewall statements in hosts
rc.conf with modules and only vimage compiled into kernel.
logger cmd on host did not work until after vnet jail was started and
stopped.
vnet jail pings passed through vnet jail but was not handed to host ipfw.
vnet jail pings got logged to hosts security file but not messages.
After vnet jail stopped, host logger cmd works and host pings work and
logged correctly to security and messages.


# /root >sysctl net.inet.ip.fw.verbose
net.inet.ip.fw.verbose: 1
# /root >sysctl net.inet.ip.fw.verbose_limit
net.inet.ip.fw.verbose_limit: 0

# /root >cat /etc/rc.comf
#
snip

firewall_enable="YES"
firewall_logging="YES"
firewall_script="/etc/ipfw.rules"



# /root >logger security.notice this msg is from logger cmd on host
# /root >cat /var/log/security
empty file
# /root >cat /var/log/messages
empty file

# /root >ping -c 4 freebsd.org
PING freebsd.org (8.8.178.135): 56 data bytes
64 bytes from 8.8.178.135: icmp_seq=0 ttl=51 time=102.814 ms
64 bytes from 8.8.178.135: icmp_seq=1 ttl=51 time=84.625 ms
64 bytes from 8.8.178.135: icmp_seq=2 ttl=51 time=101.332 ms
64 bytes from 8.8.178.135: icmp_seq=3 ttl=51 time=120.662 ms

--- freebsd.org ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 84.625/102.358/120.662/12.755 ms

# /root >cat /var/log/messages
empty file

# /root >cat /var/log/security
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept UDP 10.0.10.5:42524
209.18.47.61:53 out via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.0.10.5:42524 in via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:51 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:51 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:52 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:52 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:53 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:53 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0


# /root >logger security.notice this msg is from logger cmd on host

# /root >cat /var/log/security
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept UDP 10.0.10.5:42524
209.18.47.61:53 out via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.0.10.5:42524 in via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:51 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:51 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:52 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:52 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:53 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:53 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0


vnet jail gets started
# /root >jls
JID IP Address Hostname Path
2 - vdir2 /usr/jails/vdir2

# /root >jexec vdir2 tcsh
vdir2 / >logger -p security.notice logger cmd msg from within the host
vdir2 / >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 0 0 allow log ip from any to any via epair2b
65535 5 368 deny ip from any to any

vdir2 / >ping -c 4 freebsd.org
ping: cannot resolve freebsd.org: Host name lookup failure

vdir2 / >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 8 480 allow log ip from any to any via epair2b
65535 5 368 deny ip from any to any
vdir2 / >exit
exit

# back on the host
# /root >cat /var/log/security
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept UDP 10.0.10.5:42524
209.18.47.61:53 out via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.0.10.5:42524 in via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:50 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:51 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:51 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:52 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:52 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:05:53 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:05:53 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:10:50 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:32606
209.18.47.61:53 out via epair2b
May 2 19:10:55 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:29810
209.18.47.62:53 out via epair2b
May 2 19:10:57 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:32606
209.18.47.61:53 out via epair2b
May 2 19:11:00 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:35933
209.18.47.61:53 out via epair2b
May 2 19:11:05 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:56823
209.18.47.62:53 out via epair2b
May 2 19:11:07 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:35933
209.18.47.61:53 out via epair2b
May 2 19:11:07 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:29810
209.18.47.62:53 out via epair2b
May 2 19:11:17 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:56823
209.18.47.62:53 out via epair2b
May 2 19:11:22 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:37981
209.18.47.61:53 out via epair2b
May 2 19:11:27 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:24567
209.18.47.62:53 out via epair2b
May 2 19:11:29 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:37981
209.18.47.61:53 out via epair2b
May 2 19:11:39 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:24567
209.18.47.62:53 out via epair2b
May 2 19:11:44 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:54854
209.18.47.61:53 out via epair2b
May 2 19:11:49 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:33964
209.18.47.62:53 out via epair2b
May 2 19:11:51 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:54854
209.18.47.61:53 out via epair2b

# /root >logger -p security.notice host logger msg

# /root >cat /var/log/security
May 2 19:11:39 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:24567
209.18.47.62:53 out via epair2b
May 2 19:11:44 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:54854
209.18.47.61:53 out via epair2b
May 2 19:11:49 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:33964
209.18.47.62:53 out via epair2b
May 2 19:11:51 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:54854
209.18.47.61:53 out via epair2b
May 2 19:12:01 fbsdjones kernel: ipfw: 11 Accept UDP 10.2.0.2:33964
209.18.47.62:53 out via epair2b
May 2 19:12:50 fbsdjones root: host logger msg

# /root >cat /var/log/messages
May 2 19:08:10 fbsdjones kernel: bridge0: Ethernet address:
02:8f:94:84:0c:00
May 2 19:08:10 fbsdjones kernel: bridge0: link state changed to UP
May 2 19:08:10 fbsdjones kernel: epair2a: Ethernet address:
02:c0:a4:00:0a:0a
May 2 19:08:10 fbsdjones kernel: epair2b: Ethernet address:
02:c0:a4:00:0b:0b
May 2 19:08:10 fbsdjones kernel: epair2a: link state changed to UP
May 2 19:08:10 fbsdjones kernel: epair2b: link state changed to UP
May 2 19:12:50 fbsdjones root: host logger msg




Console log 2.
This test run is using 9.1-RELEASE with modules plus vimage and ipfw
compiled in.

options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_DEFAULT_TO_ACCEPT

logger command works. logged msg in both security and messages on host
vnet jail can ping the public internet.
Hosts security file has log messages from both jail and host.
ipfw log messages are not being put into the hosts messages file.

# ran on the host
# /root >sysctl net.inet.ip.fw.verbose
net.inet.ip.fw.verbose: 1

# /root >sysctl net.inet.ip.fw.verbose_limit
net.inet.ip.fw.verbose_limit: 0

# /root >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 0 0 allow log ip from any to any via rl0
65535 1 328 allow ip from any to any

# /root >/var/log/security
empty file

# /root >cat /var/log/messages
empty file

# /root >logger -p security.notice host logger cmd 1

# /root >cat /var/log/security
May 2 19:45:51 fbsdjones root: host logger cmd 1

# /root >cat /var/log/messages
May 2 19:45:51 fbsdjones root: host logger cmd 1

# /root >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 0 0 allow log ip from any to any via rl0
65535 1 328 allow ip from any to any

# /root >ping -c 3 freebsd.org
PING freebsd.org (8.8.178.135): 56 data bytes
64 bytes from 8.8.178.135: icmp_seq=0 ttl=51 time=85.032 ms
64 bytes from 8.8.178.135: icmp_seq=1 ttl=51 time=84.381 ms
64 bytes from 8.8.178.135: icmp_seq=2 ttl=51 time=84.647 ms

--- freebsd.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 84.381/84.687/85.032/0.267 ms

# /root >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 9 869 allow log ip from any to any via rl0
65535 1 328 allow ip from any to any

vnet jail started
# /root >jls
JID IP Address Hostname Path
1 - vdir2 /usr/jails/vdir2

# /root >jexec vdir2 tcsh

vdir2 / >cat /etc/ipfw.rules
# Flush out the list before we begin.
ipfw -q -f flush

cmd="ipfw -q add"

if [ -e /etc/epair ]; then
pif=`cat "/etc/epair"`
rm /etc/epair
else
pif="lo0"
fi

$cmd 010 allow all from any to any via lo0
$cmd 011 allow log all from any to any via $pif


vdir2 / >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 0 0 allow log ip from any to any via epair1b
65535 8 624 allow ip from any to any

vdir2 / >ping -c 3 freebsd.org
PING freebsd.org (8.8.178.135): 56 data bytes
64 bytes from 8.8.178.135: icmp_seq=0 ttl=51 time=84.342 ms
64 bytes from 8.8.178.135: icmp_seq=1 ttl=51 time=84.195 ms
64 bytes from 8.8.178.135: icmp_seq=2 ttl=51 time=84.015 ms

--- freebsd.org ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 84.015/84.184/84.342/0.134 ms

vdir2 / >ipfw -a list
00010 0 0 allow ip from any to any via lo0
00011 8 634 allow log ip from any to any via epair1b
65535 8 624 allow ip from any to any

vdir2 / >cat /var/log/security
May 1 21:56:27 vdir2 newsyslog[5202]: logfile first created

vdir2 / >cat /var/log/messages
May 1 21:56:27 vdir2 newsyslog[5202]: logfile first created

vdir2 / >exit
exit

Back on the host
# /root >cat /var/log/security
May 2 19:45:51 fbsdjones root: host logger cmd 1
May 2 19:46:53 fbsdjones kernel: ipfw: 11 Accept UDP 10.0.10.1:138
10.0.10.7:138 in via rl0
May 2 19:46:58 fbsdjones kernel: ipfw: 11 Accept UDP 10.0.10.5:64721
209.18.47.61:53 out via rl0
May 2 19:46:58 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.0.10.5:64721 in via rl0
May 2 19:46:58 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:46:58 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:46:59 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:46:59 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:47:00 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.0.10.5
8.8.178.135 out via rl0
May 2 19:47:00 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.0.10.5 in via rl0
May 2 19:47:38 fbsdjones kernel: ipfw: 11 Accept ICMPv6:143.0 [::]
[ff02::16] out via rl0
May 2 19:47:38 fbsdjones kernel: ipfw: 11 Accept ICMPv6:143.0 [::]
[ff02::16] out via rl0
May 2 19:47:39 fbsdjones kernel: ipfw: 11 Accept ICMPv6:135.0 [::]
[ff02::1:ff00:b0b] out via rl0
May 2 19:47:39 fbsdjones kernel: ipfw: 11 Accept ICMPv6:143.0 [::]
[ff02::16] out via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept UDP 10.1.0.2:13101
209.18.47.61:53 out via epair1b
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept UDP 10.1.0.2:13101
209.18.47.61:53 out via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.1.0.2:13101 in via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.1.0.2:13101 in via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept UDP 209.18.47.61:53
10.1.0.2:13101 in via epair1b
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.1.0.2
8.8.178.135 out via epair1b
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.1.0.2
8.8.178.135 out via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via rl0
May 2 19:49:21 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via epair1b
May 2 19:49:22 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.1.0.2
8.8.178.135 out via epair1b
May 2 19:49:22 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.1.0.2
8.8.178.135 out via rl0
May 2 19:49:22 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via rl0
May 2 19:49:22 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via rl0
May 2 19:49:22 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via epair1b
May 2 19:49:23 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.1.0.2
8.8.178.135 out via epair1b
May 2 19:49:23 fbsdjones kernel: ipfw: 11 Accept ICMP:8.0 10.1.0.2
8.8.178.135 out via rl0
May 2 19:49:23 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via rl0
May 2 19:49:23 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via rl0
May 2 19:49:23 fbsdjones kernel: ipfw: 11 Accept ICMP:0.0 8.8.178.135
10.1.0.2 in via epair1b

# /root >cat /var/log/messages
May 2 19:45:51 fbsdjones root: host logger cmd 1
May 2 19:47:38 fbsdjones kernel: bridge0: Ethernet address:
02:8f:94:84:0c:00
May 2 19:47:38 fbsdjones kernel: bridge0: link state changed to UP
May 2 19:47:38 fbsdjones kernel: epair1a: Ethernet address:
02:c0:24:00:0a:0a
May 2 19:47:38 fbsdjones kernel: epair1b: Ethernet address:
02:c0:24:00:0b:0b
May 2 19:47:38 fbsdjones kernel: epair1a: link state changed to UP
May 2 19:47:38 fbsdjones kernel: epair1b: link state changed to UP
May 2 19:50:59 fbsdjones kernel: epair1a: link state changed to DOWN
May 2 19:50:59 fbsdjones kernel: epair1b: link state changed to DOWN
May 2 19:50:59 fbsdjones kernel: bridge0: link state changed to DOWN
May 2 19:51:02 fbsdjones kernel: Freed UMA keg was not empty (30
items). Lost 2 pages of memory.
May 2 19:51:02 fbsdjones kernel: Freed UMA keg was not empty (203
items). Lost 1 pages of memory.
May 2 19:51:02 fbsdjones kernel: Freed UMA keg was not empty (30
items). Lost 2 pages of memory.
May 2 19:51:02 fbsdjones kernel: hhook_vnet_uninit: hhook_head type=1,
id=1 cleanup required
May 2 19:51:02 fbsdjones kernel: hhook_vnet_uninit: hhook_head type=1,
id=0 cleanup required
# /root >exit
exit

Loading...