Altq inbound queues not catching traffic

A

attley

Hi,

I have a firewall system that has outbound altq traffic shaping that is working fine. I would like to have traffic shaping on the on downstream traffic also. I assume this can be done in the internal interface when the traffic is going outside from the internal interface. The upload altq is on the external interface traffic going outside from the external interface.

These are the rules that I've configured to the firewall:
(I have written these rules based on the upload traffic shping rules)

Code: 
###inbound altq
pass quick on $int_if inet proto { tcp udp } from ($ext_if) port domain queue (in_dns)
pass quick on $int_if inet proto tcp from ($ext_if) port 22 to any queue(in_ssh)
pass quick on $int_if inet proto tcp from ($ext_if) port $im to any queue(in_services)
pass quick on $int_if inet proto icmp from ($ext_if) to any queue(in_ping)
pass quick on $int_if proto tcp from ($ext_if) to any queue(in_http, in_acks) tagged HTTP
pass quick on $int_if inet proto tcp from ($ext_if) port $torrent_orja to any queue (in_torrent)
pass quick on $int_if inet proto udp from ($ext_if) port $torrent_orja to any queue (in_torrent)
pass quick on $int_if inet proto tcp from ($ext_if) to any flags S/SA queue(in_acks)
pass quick on $int_if inet proto tcp from ($ext_if) port $steam_tcp to any queue(in_high)
pass quick on $int_if inet proto udp from ($ext_if) port $steam_udp to any queue(in_high)
pass quick on $int_if inet proto tcp from ($ext_if) port $ps3_tcp to any queue(in_high)
pass quick on $int_if inet proto udp from ($ext_if) port $ps3_udp to any queue(in_high)
pass on $int_if inet from any to any queue(in_std)


All traffic is caught by the "in_std" -queue that is the last rule. There is no http or dns traffic allthough I generate http and dns traffic while testing. Any help?
 
I doubt that ($ext_if) (i.e. the firewall itself) is the source of all traffic you want to queue, or that e.g. port 22 is the source port for any traffic. If this is a firewall, I assume it 'brokers' traffic between the Internet and machines behind the firewall? In that case the source is not the firewall's external interface, but rather the Internet at large, also known as 'any'.
 
Ok, I understand now that the logic was wrong. But if I use the rule like this:

rule for dns:
Code: 
pass quick on $int_if inet proto { tcp udp } from any queue (in_dns)

How can I tell the firewall that the downstream traffic is dns traffic? Now the "rule for dns" clearly states that ANY tcp or udp traffic is catched by the dns queue. Should I use the "tag/tagged" -options to identify certain type of traffic?
 
You can still identify the traffic based on the destination address/port so add "to $ip_of_host_on_lan port $port_on_lan_host" to your rules. This assuming the connections are initiated from the outside. If you're asking how to shape the return traffic of established outgoing connection then I don't know.
 
kpa said:
You can still identify the traffic based on the destination address/port so add "to $ip_of_host_on_lan port $port_on_lan_host" to your rules. This assuming the connections are initiated from the outside. If you're asking how to shape the return traffic of established outgoing connection then I don't know.
Click to expand...

How is that possible? Surely the connection originating from the internet doesn't connect e.g. to my LAN IP address using port dns?
 
The client will use your public IP address for connection but in filter rules you will have to use private addresses because of address rewriting (the rdr rules) that happens before the packets hit the filter engine.
 
Ok. I tried:

Code: 
pass out quick on $int_if proto { tcp udp } from any port domain to $int_if:network queue (in_dns)

but no luck. What am I not understanding in this? :D
 
Source port in tcp/udp connections is usually a random port that you don't know in advance. Change that to "from any to $int_if:network port domain ..."
I hope we are still talking about a DNS query coming from the internet to your DNS server?
 
We are not. I don't have a dns server on lan. Sorry, It seems I have mispoked completely. The thing I was trying to achieve is to make a traffic shaping to packets coming back to my private IP therefore being downstream traffic. I imagined I could do this same way I do with the upstream traffic, by catching traffic by port. Is this basically even possible and have i understood the whole thing fundamentally wrong? I do understand your point when managing a dns server eg. in lan. In that case your downstream rule seems reasonable.

My far fetched scenario:

ME ---> [int_if] -- [firewall] -- [ext_if] ---> dns queries to internet placed in "out_dns" queue (upload queue 700kb)

INTERNET ---> [ext_if] -- [firewall] -- [int_if] ---> dns replies back to my private ip placed in "in_dns" queue (download queue 4mb)

I also though the port dilemma here. How can I know the port from which the (eg google dns) is replying me from. . .
 
Yeah ok, your rule in post #7 should work because the return traffic originates from an internet host and port 53 (domain)... I'm not really an expert with traffic shaping because I've never had to set it up myself. I'm not sure how stateful tracking comes into play here, it's possible that the rule is not matched because the traffic is already part of an establised connection from the lan to the outside.
 
Outbound traffic shaping on return traffic to an inbound request (e.g. an image file sent to someone requesting it from your web server) is determined on the pass in rule for the web server. That's stateful packet filtering. Every queue statement on a pass in rule handles outbound return traffic, and a double queue (e.g. queue( traffic, acks) ) handles outbound return traffic and tcp acks (or udp low_delay in udp rules). I'm sure it's all in the documentation, and in several threads on these forums.
 
You must log in or register to reply here.
Back
Top