[ Charset ISO-8859-1 unsupported, converting... ]
> hello -
>
>
> 1) i have some rules that use proto=tcp (or proto=udp). when packets
> arrive, the fr_info_t that's built sets FI_TCPUDP for a tcp packet, and
> also for a udp packet. however, that means the fin_p field for the packet
> doesn't match the fr_proto field in the rule's frentry_t. invalidating
> the "TCPUDP means match either TCP or UDP"...
fr_proto for rules that say 'proto tcp/udp' should be 0.
So too should the mask that compares the protocol from the packet to the
rule be 0. So it does not matter that the packet does not matach the rule,
because the mask should make it irrelevant.
I suspect you are building frentry_t's yourself when you came across this
problem ?
> 2) the eccentricity mentioned above is that for some reason, if you try
> to get the ifnet* from an ifname too many times (too rapidly in sequence?),
> it returns NULL. this causes a problem in ip_state.c, when creating a
> new state entry. the entry is initialized in fr_addstate, and the ifps
> in the rule are copied into the state entry (along with the ifnames).
> after lots of initialization, shortly before fr_addstate returns, it
> calls fr_stinsert. the first thing fr_stinsert does is loop through
> the ifnames and try to lookup the ifp associated with each ifname - but
> it overwrites the previously copied (correct) ifnet* from the rule.with
> whatever is returned. my "fix" is to skip the GETIFP() call if the
> associated ifp is already initialized:
That works around your problem but it sounds like that O/S has a serious bug
that needs fixing.
> ip_state.c: fr_stinsert()
> old:
> for (i = 0; i < 4; i++) {
> name = is->is_ifname[i];
> my copy:
> for (i = 0; i < 4; i++) {
> if (is->is_ifp[i] != NULL)
> continue;
> name = is->is_ifname[i];
In doing this you also need to set to NULL all if the is_ifp pointers in
fr_stputent before calling fr_stinsert. Although I doubt that is a concern
in your case.
> 3) and 4) these are problematic. i think the issue is quite likely
> not a bug in ipfilter, but in the way it's being used. but it's also
> very possible that i just don't understand how this is supposed to work!
> it's an issue with 'keep state', and while i did go back and look
> through a couple of years' worth of the archive, i didn't see anything
> that answered my question...
>
> the switch i'm working on needs a very limited firewall on the management
> interface. it needs to accept connections for about half a dozen server
> applications, and block everything else. management connections will be
> infrequent in practice, though i use up to about 10 simultaneously in
> testing. all outbound traffic is explicitly allowed - no ports, no
> keep-states, no per-protocol rules. so i only have 12 in rules, and the
> guts of ipfilter never even sees outbound packets at all. if you want
> an explicit example of my rules:
>
> pass in quick on mgt0 proto tcp/udp from any to any port = telnet keep state
If IPFilter never sees outbound packets, "keep state" will likely not work.
Just get rid of it those words.
Darren
