Re[2]: OpenBGPD && PF
On Thursday, January 5, 2006, at 01:15:00, jared r r spiegel wrote:
> one - if you are reloading pf ( pfctl -f /etc/pf.conf ), that will
> clear the table; but that's probably not your issue.
yeah, that's normal issue and that feature works as it should ;-)
> two - if you have two peers, A and B, and both of them write to the
> same pf table , i believe the following scenario is true:
> - establish session with A and learn about 1.2.3.4/30; 1.2.3.4/30 is
> written to pftable
> - establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is
> written to pftable , but it's already there, who cares; or maybe
> it isn't written because it's already there
> either way, pftable still has 1.2.3.4/30 in it.
in my bgpd.conf there is in that way - I use the same table to match
all prefixes which are gathered through IX peerings. In both cases
above no prefixes shouldn't deleted from pftable
> - A loses its route for 1.2.3.4/30 and thus you lose it out of the
> session.
> with A, bgpd removes 1.2.3.4/30 from pftable
> it's still valid via B, but it got removed when A lost it.
It may be - however command to remove prefix from pftable comes from
bgpd not pf, right ?
> i use a unique pftable per BGP peer ( and then just reference
> each table in my pf rules in { braces } ) to avoid that
well... who knows the limit of rules in { braces } ? If you peer in IX
where you have ~50 peerings that's not a hard work to do it, but what
about 150 peerings (without route-servers) or more ?
> could be this is fixed already and one of my peers is an old version?
> ( 3.8 stable; 3.8 current dec.16; 3.8 current from oct.2 )
I've already checked that and it seems to have this behaviour on all
peerings, no matter if there is Cisco IOS, JunOS, Quagga or OpenBGPD,
so that's not that case.
--
Sylwester S. Biernacki <[EMAIL PROTECTED]>
X-NET, http://www.xnet.com.pl/
Re: OpenBGPD && PF
On Wed, Jan 04, 2006 at 09:42:44PM +0100, Sylwester S. Biernacki wrote:
>
> What do you think about it? Any ideas what to look for?
one - if you are reloading pf ( pfctl -f /etc/pf.conf ), that will
clear the table; but that's probably not your issue.
two - if you have two peers, A and B, and both of them write to the
same pf table , i believe the following scenario is true:
- establish session with A and learn about 1.2.3.4/30; 1.2.3.4/30 is
written to pftable
- establish session with B and learn about 1.2.3.4/30; 1.2.3.4/30 is
written to pftable , but it's already there, who cares; or maybe
it isn't written because it's already there
either way, pftable still has 1.2.3.4/30 in it.
- A loses its route for 1.2.3.4/30 and thus you lose it out of the session
with A, bgpd removes 1.2.3.4/30 from pftable
it's still valid via B, but it got removed when A lost it.
i use a unique pftable per BGP peer ( and then just reference
each table in my pf rules in { braces } ) to avoid that
could be this is fixed already and one of my peers is an old version?
( 3.8 stable; 3.8 current dec.16; 3.8 current from oct.2 )
--
jared
[ openbsd 3.8 GENERIC ( dec 16 ) // i386 ]
Re: rdr state problem
On Wed, Jan 04, 2006 at 03:33:36PM -0500, [EMAIL PROTECTED] wrote: > When the client refreshes, they are still redirected to the cgi, though > they can load any other pages properly. The only reason I can find for > this is the state that was created by the initial rdr (see below). Make sure you add the client address to the table BEFORE you send back the document containing the META_REFRESH. As soon as the address has been added to the table, all NEW connections will not be redirected. One explanation would be that the client is using a persistent connection to the web server, i.e. it's not closing the connection after it has gotten your document, but sends subsequent HTTP requests over that same initial connection (it's not aware of the redirection at all, and thinks it's talking to one and the same server). You should be able to confirm this theory by either tcpdump'ing all traffic from the client (looking for establishment, or lack thereof, of a second connection after the META_REFERSH is followed), or using pfctl -vvss, which should print a new, non-redirected state, if there is such a new connection. If this indeed the problem, you can force the client to abandon the first persistent connection by supplying a HTTP header from the CGI, see Persistent Connections and the "Connection: close" Header http://www.jmarshall.com/easy/http/#http1.1c3 I doubt this is in any way related to state timeouts, but I could be wrong ;) Daniel
rdr state problem
Hello, I'm trying to set up a captive portal using pf (OpenBSD snapshot from October on i386). I'm using pf rdr to direct all tcp/80 traffic to a cgi script. If a user completes the form, they are added to a table that does not get redirected and is able to access the Web. Once the client submits the form, I'd like to refresh their browser with their original request (using META_REFRESH), and this is where I'm having trouble. When the client refreshes, they are still redirected to the cgi, though they can load any other pages properly. The only reason I can find for this is the state that was created by the initial rdr (see below). I looked at per-rule timeouts, but they only appear to work on filter rules that create state. I've tried killing the state (pfctl -k), but I haven't gotten that to fix the problem, either. Does anyone have a suggestion about how to fix the problem? Thanks! Mike Here's some output from my testing: ### just after clearing everything # pfctl -vvsT -pa-r- captive_users Addresses: 0 Cleared: Wed Jan 4 14:44:21 2006 References: [ Anchors: 0 Rules: 5 ] Evaluations: [ NoMatch: 0 Match: 0 ] In/Block:[ Packets: 0 Bytes: 0 ] In/Pass: [ Packets: 0 Bytes: 0 ] In/XPass:[ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] Out/XPass: [ Packets: 0 Bytes: 0 ] # pfctl -vsa TRANSLATION RULES: nat on vr0 inet from to any -> 192.168.4.102 [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4274 ] no rdr on vr1 inet proto tcp from to any port = www [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4274 ] rdr on vr1 inet proto tcp from ! to any port = www -> 192.168.6.254 port 8080 [ Evaluations: 1 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4274 ] FILTER RULES: scrub in all fragment reassemble [ Evaluations: 1 Packets: 1 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4274 ] pass log all [ Evaluations: 1 Packets: 1 Bytes: 229 States: 0 ] [ Inserted: uid 0 pid 4274 ] State Table Total Rate current entries0 searches 10.0/s inserts00.0/s removals 00.0/s ### attempt to browse to google.com, redirected to cgi # pfctl -vsa TRANSLATION RULES: nat on vr0 inet from to any -> 192.168.4.102 [ Evaluations: 29Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4274 ] no rdr on vr1 inet proto tcp from to any port = www [ Evaluations: 34Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 4274 ] rdr on vr1 inet proto tcp from ! to any port = www -> 192.168.6.254 port 8080 [ Evaluations: 20Packets: 11Bytes: 3462States: 1 ] [ Inserted: uid 0 pid 4274 ] FILTER RULES: scrub in all fragment reassemble [ Evaluations: 84Packets: 45Bytes: 811 States: 0 ] [ Inserted: uid 0 pid 4274 ] pass log all [ Evaluations: 63Packets: 73Bytes: 10165 States: 1 ] [ Inserted: uid 0 pid 4274 ] STATES: all tcp 192.168.6.254:8080 <- 64.233.187.104:80 <- 192.168.6.51:7251 ESTABLISHED:ESTABLISHED [3810087587 + 11632] wscale 0 [3873677639 + 17376] wscale 2 age 00:00:03, expires in 04:59:58, 6:5 pkts, 811:2651 bytes, rule 0 ### after completing cgi form, still redirected to cgi, even though the client is in the captive_users table ### which should match the "no rdr" rule... # pfctl -t captive_users -T show 192.168.6.51 # pfctl -vvsT -pa-r- captive_users Addresses: 1 Cleared: Wed Jan 4 14:44:21 2006 References: [ Anchors: 0 Rules: 5 ] Evaluations: [ NoMatch: 17 Match: 0 ] In/Block:[ Packets: 0 Bytes: 0 ] In/Pass: [ Packets: 0 Bytes: 0 ] In/XPass:[ Packets: 0 Bytes: 0 ] Out/Block: [ Packets: 0 Bytes: 0 ] Out/Pass:[ Packets: 0 Bytes: 0 ] Out/XPass: [ Packets: 0 Bytes: 0 ] # pfctl -vsa TRANSLATION RULES: nat on vr0 inet from
Re: Fwd: How to determine the queue for a given state entry?
On Wed, Jan 04, 2006 at 02:00:56PM -0600, Bill Marquette wrote: > Reforwarding this...it was the holidays so maybe it got missed. > Anyone? Thanks! The queue id (ALTQ uses numerical ids, the names are just a convenient mapping provided by pf) is indeed not stored in the state entry at all. Instead, a state entry points to the rule that created it (struct pf_state.rule.ptr), which contains the queue ids (struct pf_rule.qid and .pqid). Since a state entry can persist after the rule that created it is removed from the active ruleset, the kernel keeps rules around as long as they are referenced by any state. In this case, it's not even possible to find a rule referenced by rule number in pfctl -vvss output with pfctl -vvsr (as that wouldn't print the rule anymore). If you want to merely print the queue ids used by each state entry with pfctl -vvss, the easiest way would probably be to extend the structure passed by DIOCGETSTATE to include them, pretending to userland that the state entry actually contains the queue id itself. If you want to actually modify the queue ids used by the state entry, it might be time to introduce the qid and pqid fields into the pf_state structure itself, copy them on state creation from the rule, and from then on only use the values in the state. To start with, that's just a (minor, 8 bytes per state entry) redundancy, but probably a requirement if you then want to add ioctls that modify the values in a state entry. Modifying the (possibly invisible, because already removed) underlying rule would have a different effect, changing queueing for all states created from that rule (if there are multiple). I don't know what you'd consider more useful. Referencing a state entry through ioctl is simpler than referencing a (potentially inactive) rule, I think. I guess if you provide the additional features making good use of the redundancy, and they are considered generally useful (think of some convincing real-life examples of when you want to change queueing of an existing state ;), it will be accepted. Daniel
Fwd: How to determine the queue for a given state entry?
Reforwarding this...it was the holidays so maybe it got missed. Anyone? Thanks! --Bill On 12/27/05, Bill Marquette <[EMAIL PROTECTED]> wrote: > Unless I'm missing something blatantly obvious (it wouldn't surprise > me), I can't find a way to figure out what queue a given state is > assigned. Obviously, based on rules I could logically figure it out, > but I'm looking for a way with pfctl -ss (-vvss, etc) to be able to > see what's actually in the state table. > > I've looked through a fair amount of source and grok some of what I'm > reading, but it doesn't appear that the queue is even part of the > state entry. If not, how does ALTQ actually pick up the flow? Also, > along the same lines, is it possible to modify the flows queue w/in > ALTQ? I looked for a pfioctl that would allow for state modification > - it looks like I might be able to do DIOCGETSTATE, followed by > modifying the struct and then do a DIOCKILLSTATES and a DIOCADDSTATE. > But for what I'm trying to do (change queue based on a layer 7 > protocol decode) it doesn't seem likely to help me (at this time). > Any hints? I didn't see any ioctls' specific to ALTQ either so it > doesn't appear I can access it from userland other than getting stats > through the ioctls that pf exposes. > > --Bill >
Re: graphing pf stats
[EMAIL PROTECTED] wrote: We use Cacti, Net-SNMP, and several Perl scripts to monitor our OpenBSD firewalls. https://noc.ece.uprm.edu/cacti/graph_view.php?action=tree&tree_id=2&hide=0&branch_id=734 Anyone else who is using snmp to monitor their firewalls (or who is interested in doing so) might want to check out the snmp MIB I wrote for the net-snmp agent. I use it to monitor all my firewalls along with a mix of MRTG and Cacti. http://www.packetmischief.ca/openbsd/snmp/ .joel
