Re: PF + ATLQ on openbsd 4.4
On Thu, Nov 27, 2008 at 9:32 AM, Can Erkin Acar [EMAIL PROTECTED] wrote: Damian Higgins wrote: Hi Stuart, First off, thank you for the feedback you provided. Unfortunately, you misunderstood the issue I'm encountering because you haven't read my entire post. So, I'll try to make a brief post of the previous message, to make it easier to read, and hope you will have the patience to read it this time :). Hi Can, Perhaps you are misunderstanding how pf works. I sure do, that is why I started this thread :-) Instead of trying to solve *your* problem, I will try to describe how pf+altq works, and it will be up to you to figure out how to accomplish what you want to do. First, some concepts of queueing/policing I learned from my previous experience in other environments(correct me if I'm wrong) : First forget about other environments, especially Linux. I have deleted the rest of your post, since it does not really matter what you or other environments think about how traffic shaping should be done. If you are using OpenBSD, try to understand how it is done with pf+altq. Here are the basic rules for pf. You may already know some of them, but please bear with me. You may learn something new: # Filtering is stateful in pf, and it is strongly recommended to keep it that way (ie. use 'no state' only if you really know what you are doing). The S/SA flags being default also have strong reasons. # Think of 'state' as a 'connection'. This is especially true for TCP. Use systat(1) or pftop (from ports) to see the states. A state *sees* packets in *both* directions that belong to a particular traffic. # If a packet matches a state, no rules are evaluated *hint* This is where it all starts to make sense :-) # If a packet does not match an existing state but matches a rule, a state is created. Further packets of this 'connection' will just match the state, and bypass ruleset evaluation. # Loading pf rules with 'pfctl -f pf.conf' does not clear existing states (unless you also use the proper flush command line switch) *hint* # A connection that traverses an OpenBSD router usually enters pf twice (at inbound and outbound interface) and provided there are appropriate pass rules, it will create states on both interfaces. That is, every packet of a connection both inbound and outbound will have two states associated with it. # A connection that originates from or terminates on an OpenBSD box will have a single state associated with it. # NAT/RDR rules are evaluated before filter rules, and address translation happens *before* rules are evaluated, so rules are always checked against translated packets (NAT on incoming, RDR on outgoing). And the basic rules for altq: # altq *only* filters *outbound* packets on an interface. This is usually not related to the direction of the connection itself. ## Example: if you want to restrict internal hosts HTTP downloads from outside servers, these *incoming* HTTP payloads have to be filtered at the interface facing the hosts. This also means there is no way to apply altq to limit downloads that are initiated from the OpenBSD gateway itself. ## Example: if you want to increase the priority of the e-mails that your mail server sends, use the interface facing your ISP. # Each packet, as it passes through the network stack can be assigned a 'queue-id'. This queue id determines which queue the packet is placed as it *leaves* the box. If a packet has no queue-id, then it is assigned to the default queue. # The queue ids are mapped to queue names, that is, queues that carry the same name have the same id. And this is how PF assigns packets to queues: # Each rule has two queue ids, one for normal one for high-priority packets as specified by the rule definition (see pf.conf for details). If you specified a single queue in your rule definition, that means both ids are equal. # By default the packet has no queue-id assigned. # If a packet matches a rule, and that rule specifies a queue, the packet queue-id is replaced by the queue id specified by the rule. If the rule has no queue specified, the packet queue-id is not changed (does not revert back to default). # If a packet matches a state, the rule that created the state is consulted (as above). # Since a packet can match up to two rules/states as it traverses a router, the last assigned queue wins (as the queues only take effect as the packet exits the router). # Note that, since a state matches packets in both directions, packets in both directions will be assigned queue ids by a given state. That makes it possible to create a state with a rule on one interface, and have the reply packets assigned to the same queue specified by that rule on a different interface. Finally, here are some additional things to think about or investigate: # You can do a lot of creative and flexible stuff with 'tag' and 'tagged' keywords in your
Re: PF + ATLQ on openbsd 4.4
Can Erkin Acar wrote: Damian Higgins wrote: Hi Stuart, First off, thank you for the feedback you provided. Unfortunately, you misunderstood the issue I'm encountering because you haven't read my entire post. So, I'll try to make a brief post of the previous message, to make it easier to read, and hope you will have the patience to read it this time :). Perhaps you are misunderstanding how pf works. Instead of trying to solve *your* problem, I will try to describe how pf+altq works, and it will be up to you to figure out how to accomplish what you want to do. First, some concepts of queueing/policing I learned from my previous experience in other environments(correct me if I'm wrong) : First forget about other environments, especially Linux. I have deleted the rest of your post, since it does not really matter what you or other environments think about how traffic shaping should be done. If you are using OpenBSD, try to understand how it is done with pf+altq. Here are the basic rules for pf. You may already know some of them, but please bear with me. You may learn something new: # Filtering is stateful in pf, and it is strongly recommended to keep it that way (ie. use 'no state' only if you really know what you are doing). The S/SA flags being default also have strong reasons. # Think of 'state' as a 'connection'. This is especially true for TCP. Use systat(1) or pftop (from ports) to see the states. A state *sees* packets in *both* directions that belong to a particular traffic. # If a packet matches a state, no rules are evaluated *hint* # If a packet does not match an existing state but matches a rule, a state is created. Further packets of this 'connection' will just match the state, and bypass ruleset evaluation. # Loading pf rules with 'pfctl -f pf.conf' does not clear existing states (unless you also use the proper flush command line switch) *hint* # A connection that traverses an OpenBSD router usually enters pf twice (at inbound and outbound interface) and provided there are appropriate pass rules, it will create states on both interfaces. That is, every packet of a connection both inbound and outbound will have two states associated with it. # A connection that originates from or terminates on an OpenBSD box will have a single state associated with it. # NAT/RDR rules are evaluated before filter rules, and address translation happens *before* rules are evaluated, so rules are always checked against translated packets (NAT on incoming, RDR on outgoing). And the basic rules for altq: # altq *only* filters *outbound* packets on an interface. This is usually not related to the direction of the connection itself. ## Example: if you want to restrict internal hosts HTTP downloads from outside servers, these *incoming* HTTP payloads have to be filtered at the interface facing the hosts. This also means there is no way to apply altq to limit downloads that are initiated from the OpenBSD gateway itself. ## Example: if you want to increase the priority of the e-mails that your mail server sends, use the interface facing your ISP. # Each packet, as it passes through the network stack can be assigned a 'queue-id'. This queue id determines which queue the packet is placed as it *leaves* the box. If a packet has no queue-id, then it is assigned to the default queue. # The queue ids are mapped to queue names, that is, queues that carry the same name have the same id. And this is how PF assigns packets to queues: # Each rule has two queue ids, one for normal one for high-priority packets as specified by the rule definition (see pf.conf for details). If you specified a single queue in your rule definition, that means both ids are equal. # By default the packet has no queue-id assigned. # If a packet matches a rule, and that rule specifies a queue, the packet queue-id is replaced by the queue id specified by the rule. If the rule has no queue specified, the packet queue-id is not changed (does not revert back to default). # If a packet matches a state, the rule that created the state is consulted (as above). # Since a packet can match up to two rules/states as it traverses a router, the last assigned queue wins (as the queues only take effect as the packet exits the router). # Note that, since a state matches packets in both directions, packets in both directions will be assigned queue ids by a given state. That makes it possible to create a state with a rule on one interface, and have the reply packets assigned to the same queue specified by that rule on a different interface. Finally, here are some additional things to think about or investigate: # You can do a lot of creative and flexible stuff with 'tag' and 'tagged' keywords in your ruleset. Assigning queues by 'pass quick tagged XYZZY queue MAGIC' type of rules is much easier to keep track of. # What happens
Re: PF + ATLQ on openbsd 4.4
Hi Stuart,
First off, thank you for the feedback you provided. Unfortunately, you
misunderstood the issue I'm encountering because you haven't read my
entire post. So, I'll try to make a brief post of the previous
message, to make it easier to read, and hope you will have the
patience to read it this time :).
First, some concepts of queueing/policing I learned from my previous
experience in other environments(correct me if I'm wrong) :
In order to apply downstream queueing/policing for a particular host one can :
- match host's destination ip address on the interface towards the
host and implement queueing on the interface towards the host.
- match host's destination ip address on interfaces towards the ISP
and implement queueing on the interface towards the host. (!!! only if
there is no NAT involved!!!, otherwise it is the outside interface IP
address that has to be matched as a destination, but this somehow
defeats the purpose, since the most common NAT scenario is that
multiple hosts get translated to a single outside address and it will
end up that the downstream of all hosts gets queued. It would only be
a succesfull queing policy on scenarios where 1-to-1 NAT mapping is
applied.)
In order to apply upstream queueing/policing for a particular host one can :
- match the host's source ip address on the interface towards the ISP
and implement queueing on the interface towards the ISP.
- match the host's source ip address on the interface towards the host
and implement rate limiting(ingress policy) on the interface towards
the host.
- when NAT is involved, mark/tag host's source ip address on the
interface towards the host and implement queueing on the interface
towards the ISP based on mark/tag.
Now, on openbsd, in order to succefully get downstream queue policy
for a particular host (192.168.110.2) I was forced to match the
destination address of a specific location (86.55.8.30) from where the
host was downloading on the interface towards the host.
This is really nonsense to me since pass out quick on em0 to
86.55.8.30 queue ftp or pass in quick on em1 to 86.55.8.30 queue
ftp it's clearly uptream queueing (em0 is ISP side and em1 host side
and ALTQ was only appplied on em1 interface).
If I apply the queue designation rules according to my understandings
nothing gets matched/queued :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
pass out log(all) quick on em1 from 86.55.8.30 to 192.168.110.2 queue ftp
pass in log(all) quick on em0 from 86.55.8.30 to 192.168.110.2 queue ftp
pass log(all) all
tcpdump -nettipflog0 src host 86.55.8.30 and dst host 192.168.110.2
shows that packets bypass the first two rules hitting the last one
directly :
1227709000.698775 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.698892 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.698895 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699016 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699019 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699139 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699141 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699265 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699268 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699389 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699393 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699518 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699521 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699638 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699641 rule 2/(match) pass out on em1: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
1227709000.699763 rule 2/(match) pass in on em0: 86.55.8.30.27304
192.168.110.2.3202: [|tcp] (DF)
So why do these packets bypass the first rules ?
Thank you and regards.
On Tue, Nov 25, 2008 at 11:47 PM, Stuart Henderson [EMAIL PROTECTED] wrote:
On 2008-11-25, Damian Higgins [EMAIL PROTECTED] wrote:
According to what pf logged, it permits traffic incoming on em1 to
86.55.8.30 and outgoing trafic on em0 to 86.55.8.30. So I modified
my designation rule to :
pass out quick on em0 to 86.55.8.30 queue ftp
And traffic started hitting the first rule :
Good.
So it seems
Re: PF + ATLQ on openbsd 4.4
Damian Higgins wrote: Hi Stuart, First off, thank you for the feedback you provided. Unfortunately, you misunderstood the issue I'm encountering because you haven't read my entire post. So, I'll try to make a brief post of the previous message, to make it easier to read, and hope you will have the patience to read it this time :). Perhaps you are misunderstanding how pf works. Instead of trying to solve *your* problem, I will try to describe how pf+altq works, and it will be up to you to figure out how to accomplish what you want to do. First, some concepts of queueing/policing I learned from my previous experience in other environments(correct me if I'm wrong) : First forget about other environments, especially Linux. I have deleted the rest of your post, since it does not really matter what you or other environments think about how traffic shaping should be done. If you are using OpenBSD, try to understand how it is done with pf+altq. Here are the basic rules for pf. You may already know some of them, but please bear with me. You may learn something new: # Filtering is stateful in pf, and it is strongly recommended to keep it that way (ie. use 'no state' only if you really know what you are doing). The S/SA flags being default also have strong reasons. # Think of 'state' as a 'connection'. This is especially true for TCP. Use systat(1) or pftop (from ports) to see the states. A state *sees* packets in *both* directions that belong to a particular traffic. # If a packet matches a state, no rules are evaluated *hint* # If a packet does not match an existing state but matches a rule, a state is created. Further packets of this 'connection' will just match the state, and bypass ruleset evaluation. # Loading pf rules with 'pfctl -f pf.conf' does not clear existing states (unless you also use the proper flush command line switch) *hint* # A connection that traverses an OpenBSD router usually enters pf twice (at inbound and outbound interface) and provided there are appropriate pass rules, it will create states on both interfaces. That is, every packet of a connection both inbound and outbound will have two states associated with it. # A connection that originates from or terminates on an OpenBSD box will have a single state associated with it. # NAT/RDR rules are evaluated before filter rules, and address translation happens *before* rules are evaluated, so rules are always checked against translated packets (NAT on incoming, RDR on outgoing). And the basic rules for altq: # altq *only* filters *outbound* packets on an interface. This is usually not related to the direction of the connection itself. ## Example: if you want to restrict internal hosts HTTP downloads from outside servers, these *incoming* HTTP payloads have to be filtered at the interface facing the hosts. This also means there is no way to apply altq to limit downloads that are initiated from the OpenBSD gateway itself. ## Example: if you want to increase the priority of the e-mails that your mail server sends, use the interface facing your ISP. # Each packet, as it passes through the network stack can be assigned a 'queue-id'. This queue id determines which queue the packet is placed as it *leaves* the box. If a packet has no queue-id, then it is assigned to the default queue. # The queue ids are mapped to queue names, that is, queues that carry the same name have the same id. And this is how PF assigns packets to queues: # Each rule has two queue ids, one for normal one for high-priority packets as specified by the rule definition (see pf.conf for details). If you specified a single queue in your rule definition, that means both ids are equal. # By default the packet has no queue-id assigned. # If a packet matches a rule, and that rule specifies a queue, the packet queue-id is replaced by the queue id specified by the rule. If the rule has no queue specified, the packet queue-id is not changed (does not revert back to default). # If a packet matches a state, the rule that created the state is consulted (as above). # Since a packet can match up to two rules/states as it traverses a router, the last assigned queue wins (as the queues only take effect as the packet exits the router). # Note that, since a state matches packets in both directions, packets in both directions will be assigned queue ids by a given state. That makes it possible to create a state with a rule on one interface, and have the reply packets assigned to the same queue specified by that rule on a different interface. Finally, here are some additional things to think about or investigate: # You can do a lot of creative and flexible stuff with 'tag' and 'tagged' keywords in your ruleset. Assigning queues by 'pass quick tagged XYZZY queue MAGIC' type of rules is much easier to keep track of. # What happens if you change the ruleset while traffic is flowing? Hint: existing
Re: PF + ATLQ on openbsd 4.4
Hi Stuart,
The ftp server is on em0 side and the initiator is 192.168.110.2 and
is on em1 side:
86.55.8.30(ftp sever) em0(192.168.100.233)-OpenBSD
box-(192.168.110.1)em1 192.168.110.2(initiator).
I have modified my rules according to Giancarlo's recomandation and
removed the flags any statement :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 - 192.168.100.233
pass in quick on em0 from 86.55.8.30 queue ftp
pass log all
I started a new ftp sesion from 192.168.110.2 and this is what pf logged :
1227628112.272991 rule 1/(match) pass in on em1: 192.168.110.2.3061
86.55.8.30.21: [|tcp] (DF)
1227628112.273000 rule 1/(match) pass out on em0:
192.168.100.233.50909 86.55.8.30.21: [|tcp] (DF)
1227628112.297853 rule 1/(match) pass in on em1: 192.168.110.2.3063
86.55.8.30.49723: [|tcp] (DF)
1227628112.297861 rule 1/(match) pass out on em0:
192.168.100.233.62166 86.55.8.30.49723: [|tcp] (DF)
1227628112.307175 rule 1/(match) pass in on em1: 192.168.110.2.3065
86.55.8.30.18917: [|tcp] (DF)
1227628112.307183 rule 1/(match) pass out on em0:
192.168.100.233.53378 86.55.8.30.18917: [|tcp] (DF)
1227628136.780448 rule 1/(match) pass in on em1: 192.168.110.2.3069
86.55.8.30.14919: [|tcp] (DF)
1227628136.780457 rule 1/(match) pass out on em0:
192.168.100.233.53489 86.55.8.30.14919: [|tcp] (DF)
1227628136.807671 rule 1/(match) pass in on em1: 192.168.110.2.3071
86.55.8.30.2344: [|tcp] (DF)
1227628136.807678 rule 1/(match) pass out on em0:
192.168.100.233.62091 86.55.8.30.2344: [|tcp] (DF)
1227628139.661602 rule 1/(match) pass in on em1: 192.168.110.2.3073
86.55.8.30.30207: [|tcp] (DF)
1227628139.661610 rule 1/(match) pass out on em0:
192.168.100.233.56393 86.55.8.30.30207: [|tcp] (DF)
1227628139.675897 rule 1/(match) pass in on em1: 192.168.110.2.3075
86.55.8.30.47420: [|tcp] (DF)
1227628139.675904 rule 1/(match) pass out on em0:
192.168.100.233.54381 86.55.8.30.47420: [|tcp] (DF)
1227628144.398885 rule 1/(match) pass in on em1: 192.168.110.2.3077
86.55.8.30.22614: [|tcp] (DF)
1227628144.398893 rule 1/(match) pass out on em0:
192.168.100.233.56068 86.55.8.30.22614: [|tcp] (DF)
0 packets hit the first rule :
~# pfctl -sr -vv
@0 pass in quick on em0 inet from 86.55.8.30 to any flags S/SA keep
state queue ftp
[ Evaluations: 2074 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 19345 State Creations: 0 ]
@1 pass log all flags S/SA keep state
[ Evaluations: 2076 Packets: 56520 Bytes: 52131049States: 63]
[ Inserted: uid 0 pid 19345 State Creations: 1390 ]
I replaced pass in quick on em0 from 86.55.8.30 queue ftp with pass
out quick on em1 from 86.55.8.30 queue ftp and made
the test again :
tcpdump -nettipflog0 host 86.55.8.30 :
1227630608.794664 rule 1/(match) pass in on em1: 192.168.110.2.3433
86.55.8.30.21: [|tcp] (DF)
1227630608.794672 rule 1/(match) pass out on em0:
192.168.100.233.57968 86.55.8.30.21: [|tcp] (DF)
1227630608.923694 rule 1/(match) pass in on em1: 192.168.110.2.3435
86.55.8.30.63973: [|tcp] (DF)
1227630608.923701 rule 1/(match) pass out on em0:
192.168.100.233.55330 86.55.8.30.63973: [|tcp] (DF)
Again, 0 packets hit the first rule :
:~# pfctl -sr -vv
@0 pass out quick on em1 inet from 86.55.8.30 to any flags S/SA keep
state queue ftp
[ Evaluations: 267 Packets: 0 Bytes: 0 States: 0 ]
[ Inserted: uid 0 pid 10640 State Creations: 0 ]
@1 pass log all flags S/SA keep state
[ Evaluations: 269 Packets: 37149 Bytes: 41268847States: 96]
[ Inserted: uid 0 pid 10640 State Creations: 96]
According to what pf logged, it permits traffic incoming on em1 to
86.55.8.30 and outgoing trafic on em0 to 86.55.8.30. So I modified
my designation rule to :
pass out quick on em0 to 86.55.8.30 queue ftp
And traffic started hitting the first rule :
~# pfctl -sr -vv
@0 pass out quick on em0 inet from any to 86.55.8.30 flags S/SA keep
state queue ftp
[ Evaluations: 374 Packets: 3452 Bytes: 3658907 States: 2 ]
[ Inserted: uid 0 pid 753 State Creations: 2 ]
@1 pass log all flags S/SA keep state
[ Evaluations: 374 Packets: 3564 Bytes: 3694526 States: 28]
[ Inserted: uid 0 pid 753 State Creations: 32]
I made another test and designated the queue on the same interface
where ALTQ policy was aplied :
pass in quick on em1 to 86.55.8.30 queue ftp
Traffic also got matched by this rule succesfully :
~# pfctl -sr -vv
@0 pass in quick on em1 inet from any to 86.55.8.30 flags S/SA keep
state queue ftp
[ Evaluations: 806 Packets: 2186 Bytes: 2294367 States: 2 ]
[ Inserted: uid 0 pid 27436 State Creations: 2 ]
@1 pass log all flags S/SA keep state
[ Evaluations: 806 Packets: 2223 Bytes: 2298770
Re: PF + ATLQ on openbsd 4.4
On 2008-11-25, Damian Higgins [EMAIL PROTECTED] wrote:
According to what pf logged, it permits traffic incoming on em1 to
86.55.8.30 and outgoing trafic on em0 to 86.55.8.30. So I modified
my designation rule to :
pass out quick on em0 to 86.55.8.30 queue ftp
And traffic started hitting the first rule :
Good.
So it seems http://www.openbsd.org/faq/pf/queueing.html is outdated
since it says queue designation should take place on a different
interface than the one where queueing policy is applied.
do you mean this, Note that queue designation /can/ happen on
an interface other than the one defined in the altq on directive?
(my emphasis)..
The result of the above queue designation rules was a constantly 1mbit
download rate for the initiator (192.168.110.2). So my understanding
is that ALTQ is per flow/session connection oriented rather than per
source/destination.
the rules assign traffic to a queue, the bandwidth available for
the queue is shared between all traffic assigned to it.
if you're looking to limit each individual user to 1Mb/s, but not
impose a total limit, altq can't really help.
I didn't read everything of the rest of your post but hopefully the
things I mention will help understanding:
pass in quick on em0 from 86.55.8.30 queue ftp and pass out quick
on em1 from 86.55.8.30 queue ftp matched nothing
pass out quick on em0 to 86.55.8.30 queue ftp , pass in quick on
em1 to 86.55.8.30 queue ftp (which looks more like ingress rate
limiting to me) matched trafic and it is the trafic back to the
initiator that got queued.
with altq, queueing happens when packets exit an interface, the only
thing you can do at ingress is create state with a queue name attached
so that any later traffic matching that state uses that queue.
for traffic you are passing to other hosts, you can fake up ingress
rate limiting by controlling the rate you feed those packets out,
so for protocols which have rate control (like TCP) it will indirectly
affect the sender's rate.
So for 192.168.6.216(initiator)'s downstream queueing I set up the
following pf rules :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em0 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em0 bandwidth 2Mb priority 0 cbq(ecn)
queue other on em0 bandwidth 98Mb priority 1 cbq(ecn,default)
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 to test - 192.168.100.233
table test { any , !192.168.0.0/16 }
pass in quick on em0 to 192.168.110.2 queue ftp
pass log all
Then started a ftp session from 192.168.6.216 with 192.168.110.2 on
port 2121 but nothing got matched, it was only a few packets at
beginning of the session :
look into how the protocol works and you'll see you have to handle
the FTP _data_ connections as well as the control connections, these
are potentially made in either direction (for passive mode, the client
makes a second connection to the server, for active mode the server
connects back to the client).
if you haven't seen it before, look at the actual packet contents
on the interface (tcpdump -niem0 -s1500 -X host some.ftp.server)
while connecting to an FTP server and listing a directory (which,
like transferring a file, also opens an extra connection).
note where new connections are opened (the letter S after the
destination port) and in which direction.
if you think you've got it, it can be educational to manually
carry out an ftp transfer, you can do passive mode just with
the telnet command in two windows, for active mode you also
need something like netcat (/usr/bin/nc) which can listen for
an incoming connection.
~# tcpdump -nettipflog0 | grep -E 192.168.110.2\|192.168.6.216
using grep on tcpdump output will catch you out. you could use
line-buffered mode (-l) but better to use tcpdump expressions to
select the traffic you're interested in. at least on OpenBSD,
this works fine on pflog0. on other OS, YMMV.
[also note, on pflog, by default only packets _creating state_
are logged, you can log the others if you use log (all)]
PF + ATLQ on openbsd 4.4
Hi,
I'm trying to set up a simple packet queueing policy on openbsd 4.4.
These are the PF rules I set up :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 - 192.168.100.233
pass in quick on em0 from 86.55.8.30 flags any queue ftp
pass all
IP alocation on interfaces :
~# ifconfig
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 33160
groups: lo
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:15:17:20:9e:94
groups: egress
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 192.168.100.233 netmask 0xff00 broadcast 192.168.100.255
inet6 fe80::215:17ff:fe20:9e94%em0 prefixlen 64 scopeid 0x1
em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500
lladdr 00:15:17:20:9e:95
media: Ethernet autoselect (100baseTX full-duplex,rxpause,txpause)
status: active
inet 192.168.110.1 netmask 0xff00 broadcast 192.168.110.255
inet6 fe80::215:17ff:fe20:9e95%em1 prefixlen 64 scopeid 0x2
The issue that I have is that traffic from 86.55.8.30 doesn't get
matched by the pass in quick on em0 from 86.55.8.30 flags any queue
ftp rule and nothing gets queued.
This is a snip of tcpdump -vv -n -i em0 host 86.55.8.30 after I
loaded the PF rules and started ftp trafic :
19:39:53.074118 86.55.8.30.59355 192.168.100.233.51640: .
8429709:8431169(1460) ack 1 win 5840 (DF) (ttl 57, id 34206, len 1500)
19:39:53.074242 86.55.8.30.59355 192.168.100.233.51640: .
8431169:8432629(1460) ack 1 win 5840 (DF) (ttl 57, id 34207, len 1500)
19:39:53.074341 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 1 {8420949:8422409}
(DF) (ttl 127, id 14110, len 52)
19:39:53.074367 86.55.8.30.59355 192.168.100.233.51640: P
8432629:8434089(1460) ack 1 win 5840 (DF) (ttl 57, id 34208, len 1500)
19:39:53.074491 86.55.8.30.59355 192.168.100.233.51640: .
8434089:8435549(1460) ack 1 win 5840 (DF) (ttl 57, id 34209, len 1500)
19:39:53.074594 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8429709}
{8420949:8422409} (DF) (ttl 127, id 14120, len 60)
19:39:53.074595 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8431169}
{8420949:8422409} (DF) (ttl 127, id 14121, len 60)
19:39:53.074596 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8432629}
{8420949:8422409} (DF) (ttl 127, id 14122, len 60)
19:39:53.074615 86.55.8.30.59355 192.168.100.233.51640: .
8435549:8437009(1460) ack 1 win 5840 (DF) (ttl 57, id 34210, len 1500)
19:39:53.074739 86.55.8.30.59355 192.168.100.233.51640: P
8437009:8438469(1460) ack 1 win 5840 (DF) (ttl 57, id 34211, len 1500)
19:39:53.074838 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8434089}
{8420949:8422409} (DF) (ttl 127, id 14140, len 60)
19:39:53.074864 86.55.8.30.59355 192.168.100.233.51640: .
8416569:8418029(1460) ack 1 win 5840 (DF) (ttl 57, id 34212, len 1500)
19:39:53.074964 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8435549}
{8420949:8422409} (DF) (ttl 127, id 14141, len 60)
19:39:53.074965 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8437009}
{8420949:8422409} (DF) (ttl 127, id 14142, len 60)
19:39:53.075211 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8416569 win 65535 nop,nop,sack 2 {8428249:8438469}
{8420949:8422409} (DF) (ttl 127, id 14145, len 60)
19:39:53.075983 86.55.8.30.59355 192.168.100.233.51640: .
8418029:8419489(1460) ack 1 win 5840 (DF) (ttl 57, id 34213, len 1500)
19:39:53.076232 86.55.8.30.59355 192.168.100.233.51640: .
8419489:8420949(1460) ack 1 win 5840 (DF) (ttl 57, id 34214, len 1500)
19:39:53.076578 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8422409 win 65535 nop,nop,sack 1 {8428249:8438469}
(DF) (ttl 127, id 14146, len 52)
19:39:53.077847 86.55.8.30.59355 192.168.100.233.51640: .
8439929:8441389(1460) ack 1 win 5840 (DF) (ttl 57, id 34220, len 1500)
19:39:53.078443 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack 8422409 win 65535 nop,nop,sack 2 {8439929:8441389}
{8428249:8438469} (DF) (ttl 127, id 14156, len 60)
19:39:53.079712 86.55.8.30.59355 192.168.100.233.51640: .
8441389:8442849(1460) ack 1 win 5840 (DF) (ttl 57, id 34221, len 1500)
19:39:53.080307 192.168.100.233.51640 86.55.8.30.59355: . [tcp sum
ok] 1:1(0) ack
Re: PF + ATLQ on openbsd 4.4
On Monday 24 November 2008 17.24.04 you wrote:
Hi,
I'm trying to set up a simple packet queueing policy on openbsd 4.4.
These are the PF rules I set up :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 - 192.168.100.233
pass in quick on em0 from 86.55.8.30 flags any queue ftp
pass all
You specified the queue for em1, and you created the rule for em0.
Daniel
--
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: PF + ATLQ on openbsd 4.4
Hi Daniel,
Well, I know this is weird, I come from a linux environment myself,
but according to http://www.openbsd.org/faq/pf/queueing.html queue
designation should take place on another interface than the one where
queueing is applied :
Note that queue designation can happen on an interface other than the
one defined in the altq on directive:
altq on fxp0 cbq bandwidth 2Mb queue { std, ftp }
queue std bandwidth 500Kb cbq(default)
queue ftp bandwidth 1.5Mb
pass in on dc0 from any to any port 21 queue ftp
Queueing is enabled on fxp0 but the designation takes place on dc0. If
packets matching the pass rule exit from interface fxp0, they will be
queued in the ftp queue. This type of queueing can be very useful on
routers.
However, I did try to apply the queue designation on em1 interface
with the statement pass out quick on em1 from 86.55.8.30 flags any
queue ftp but got the same result. Nothing got matched. I'll paste
the outputs tomorrow because I don't have access to that particular
machine right now.
Thank you and regards.
On Mon, Nov 24, 2008 at 8:37 PM, LIVAI Daniel [EMAIL PROTECTED] wrote:
On Monday 24 November 2008 17.24.04 you wrote:
Hi,
I'm trying to set up a simple packet queueing policy on openbsd 4.4.
These are the PF rules I set up :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 - 192.168.100.233
pass in quick on em0 from 86.55.8.30 flags any queue ftp
pass all
You specified the queue for em1, and you created the rule for em0.
Daniel
--
LEVAI Daniel
PGP key ID = 0x4AC0A4B1
Key fingerprint = D037 03B9 C12D D338 4412 2D83 1373 917A 4AC0 A4B1
Re: PF + ATLQ on openbsd 4.4
On 2008-11-24, LIVAI Daniel [EMAIL PROTECTED] wrote:
On Monday 24 November 2008 17.24.04 you wrote:
Hi,
I'm trying to set up a simple packet queueing policy on openbsd 4.4.
These are the PF rules I set up :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 - 192.168.100.233
pass in quick on em0 from 86.55.8.30 flags any queue ftp
pass all
You specified the queue for em1, and you created the rule for em0.
Not necessarily a problem. But it could be.
Lots of missing information here. Where's the ftp server? Which side
initiates the connection (this will vary depending on active/passive)?
Etc.
Looking through and working out what information people might need
to answer the question, will probably suggest why the state gets created
for the pass all rule rather than the pass in ... from ... rule.
Re: PF + ATLQ on openbsd 4.4
LIVAI Daniel escreveu:
On Monday 24 November 2008 17.24.04 you wrote:
Hi,
I'm trying to set up a simple packet queueing policy on openbsd 4.4.
These are the PF rules I set up :
~# grep -v \# /etc/pf.conf | grep -v ^$
altq on em1 cbq bandwidth 100Mb queue { ftp,other }
queue ftp on em1 bandwidth 1Mb priority 0 cbq(ecn)
queue other on em1 bandwidth 99Mb priority 1 cbq(ecn,default)
nat on em0 from 192.168.110.2 - 192.168.100.233
pass in quick on em0 from 86.55.8.30 flags any queue ftp
pass all
You specified the queue for em1, and you created the rule for em0.
Daniel
Not necessarily an error, since you can assign packets from one
interface to queue of others interfaces. We need more info to help, like
your interfaces configuration.
My regards,
--
Giancarlo Razzolini
http://lock.razzolini.adm.br
Linux User 172199
Red Hat Certified Engineer no:804006389722501
Verify:https://www.redhat.com/certification/rhce/current/
Moleque Sem Conteudo Numero #002
OpenBSD Stable
Ubuntu 8.04 Hardy Heron
4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
Re: PF + ATLQ on openbsd 4.4
On 2008-11-24, Damian Higgins [EMAIL PROTECTED] wrote: However, I did try to apply the queue designation on em1 interface with the statement pass out quick on em1 from 86.55.8.30 flags any queue ftp but got the same result. Nothing got matched. I'll paste the outputs tomorrow because I don't have access to that particular machine right now. try just pass log all and tcpdump -nettipflog0. it will show the interface and direction of all the packets which create state. nice and easy to convert this to rules which will get matched.
Re: PF + ATLQ on openbsd 4.4
Damian Higgins escreveu: Hi Giancarlo, I pasted my interfaces configuration at the beggining of the thread but you've probably missed it, let me know if you need other parameters than : Sorry, i missed it. Have you tried setting up the altq on the em0 interface? Also, i suggest that you remove the flags any from the rule. Also, when i want to debug something i put the log modifier in it to see if it was matched with the pflog. My regards, -- Giancarlo Razzolini http://lock.razzolini.adm.br Linux User 172199 Red Hat Certified Engineer no:804006389722501 Verify:https://www.redhat.com/certification/rhce/current/ Moleque Sem Conteudo Numero #002 OpenBSD Stable Ubuntu 8.04 Hardy Heron 4386 2A6F FFD4 4D5F 5842 6EA0 7ABE BBAB 9C0E 6B85
