Questions and Answers
Amy Rich
Q We just installed a new batch of Solaris 9 machines
where I work. These machines are of different types (280Rs, V120s, V240s,
V490s, V1280s, etc.), and on some of them, it looks like ipfilter refuses to
work on the public interface. This doesn’t seem to be consistent across
hardware types, though. In each case where ipfilter is failing, I’ve reduced
the rulesets to the absolute bare minimum. Here’s an example from one of our
280Rs:
block in log level local3.info quick on hme0 all
block out log level local3.info quick on hme0 all
block in log level local3.info quick on eri0 all
block in log level local3.info quick on eri0 all
To prove that it’s picking up the rules correctly, here’s
the ipfstat -io output:
block out log level local3.info quick on hme0 all
block out log level local3.info quick on eri0 all
block in log level local3.info quick on hme0 all
block in log level local3.info quick on eri0 all
When I try to ping the machine using the private
interface (eri0), the packets are blocked, and I get a timeout on the ping.
Here’s the corresponding ipfstat -d output:
bad packets: in 0 out 0
IPv6 packets: in 0 out 0
input packets: blocked 49 passed 0 nomatch 0 counted 0 short 0
output packets: blocked 0 passed 0 nomatch 0 counted 0 short 0
input packets logged: blocked 49 passed 0 output packets logged: blocked 0 passed 0
packets logged: input 0 output 0
log failures: input 0 output 0
fragment state(in): kept 0 lost 0 not fragmented 0
fragment state(out): kept 0 lost 0 not fragmented 0
packet state(in): kept 0 lost 0
packet state(out): kept 0 lost 0
ICMP replies: 0 TCP RSTs sent: 0
Invalid source(in): 0
Result cache hits(in): 29 (out): 0
IN Pullups succeeded: 0 failed: 0
OUT Pullups succeeded: 0 failed: 0
Fastroute successes: 0 failures: 0
TCP cksum fails(in): 0 (out): 0
IPF Ticks: 265
Packet log flags set: (0)
none
And when I ping the external interface (hme0), it answers
right away! If I do another ipfstat -d, it doesn’t show any packets passed,
which is very odd.
|
