[Firehol-support] FireQOS matching by MAC address

Sun Aug 24 04:15:22 CEST 2014

Hi Phineas,

good to know it is working.

You could also apply QoS on the WAN side too. This will guarrantee the
operation of your dns and openvpn servers.

About the examples, I can give you access to commit wiki pages on github.
You can submit your own documented examples there and when Phil and I will
find some time to work on the FireQOS documentation we will try to
incorporate your examples. I just need your github username for that.

Thanks.

Costa

On Sat, Aug 23, 2014 at 3:26 PM, Phineas Gage <phineas919 at gmail.com> wrote:

> Thanks, it’s working well now, shaping on the LAN interface. Both the
> srcmac and dstmac keywords are working, and as you said, the MAC addresses
> are available to me now that shaping is done on the LAN side.
>
> This is great, because I’ve enabled IPv6, and both IPv4 and IPv6 traffic
> classifies properly. With IPv6, most OSs have RFC 4941 privacy extensions
> enabled by default, so when SLAAC is used, which is the case for us,
> addresses change very frequently. With more complicated IPv6 subnetting
> setups than ours where MAC addresses can’t be used, DHCPv6 could be used
> instead of SLAAC to give out consistent addresses, so they could be shaped
> or firewalled using src6/dst6.
>
> As described in the "FireQOS Use Scenarios" you sent, I know the shaping
> isn't perfect, because the same Linux box that does shaping is also an
> OpenVPN server, although very infrequently. Facing internally is a caching
> DNS server and an NTP server. Those servers can make requests as clients on
> the WAN side, and other occasional WAN requests may be made, like for
> automatic upgrades. Any traffic to the LAN side interface is classified as
> LAN and isn’t under my "adsl" group, so that’s fine, but any WAN access
> (both client and server, right?) can throw off the QoS calculations. So
> far, it’s not much of an issue for me.
>
> Also, I’m not proud of my IPv6 setup, because I’ve got static routes on
> the ADSL modem back to the Linux router, with static IP addresses. If our
> external /64 prefix ever changes, and it probably will, IPv6 will break. So
> soon, I’d like to switch to bridging with transparent firewalling/shaping,
> which I’m hoping FireHOL and FireQOS will help with.
>
> If you guys need more FireQOS example configurations for documentation, I
> could be willing to contribute mine, just let me know if it would be
> useful. I found the “FireQOS Use Scenarios” helpful, but since it’s not on
> firehol.org, I’m not sure everyone finds it.
>
> On Aug 18, 2014, at 3:27 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>
> 1) it will be a little tricky, especially if your linux router has other
> functions as well, for which you will most probably need full speed access
> and you also need ADSL overheads calculation. Check the last example in
> this page: https://github.com/ktsaou/firehol/wiki/FireQOS-Use-Scenarios.
> It will give you the idea.
>
> Regaring marks, unfortunatelly IFBs are before netfilter, so marks cannot
> be used on incoming traffic. If you do it on the LAN side though, you will
> have all the info needed.
>
>
> On Mon, Aug 18, 2014 at 3:27 PM, Phineas Gage <phineas919 at gmail.com>
> wrote:
>
>> 1) Are there any problems you can think of with using QoS on the LAN side
>> to shape Internet traffic? I’ve never heard of doing it this way, but can
>> try it if it’ll work.
>>
>> 2) Thanks for the clarification, will be more careful with masquerade…
>>
>> PS- By the way, I tried using connmark in my firehol.conf to classify
>> traffic coming in on the LAN side by MAC address, then using “match mark #”
>> in fireqos.conf. That worked for the outgoing traffic, but the mark
>> wouldn’t restore to classify incoming traffic into eth1 or eth1-ifb (the
>> WAN side). Probably because the IFB stuff happens outside of netfilter.
>>
>> On Aug 18, 2014, at 1:55 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>>
>> 1) I don't think there is a way to place QoS to any other place. Both
>> ingress and egress QoS are applied outside netfilter and routing. So, your
>> only option is to apply QoS on the LAN side, not the WAN.
>>
>> 2) masquerade is applied on the outface of routers. It does not limit the
>> traffic further. Everything on the outface will be masqueraded. If you want
>> to limit it, you have to add optional rule parameters to the masquerade
>> yourself. Keep in mind though that inface matches are not possible there.
>> Check the manual: http://firehol.org/firehol-manual/firehol-masquerade/
>>
>> Costa
>>
>>
>>
>> On Mon, Aug 18, 2014 at 11:49 AM, Phineas Gage <phineas919 at gmail.com>
>> wrote:
>>
>>> 1)
>>>
>>> Thanks Costa, the srcmac and dstmac parameters do seem to work.
>>>
>>> But in my situation, I may not be able to use them. The reason is, the
>>> MAC address that’s matched is the one after routing has occurred. I shape
>>> traffic on eth1, my external interface, and of course, the source and
>>> destination MAC addresses for traffic going in and out of eth1 are always
>>> the MAC address for eth1.
>>>
>>> It would be great if you could match by source or destination IP, MAC
>>> address or ports either before or after routing has occurred. Earlier this
>>> year, I had to stop using NAT on my firewall/router in order for IP based
>>> classification to work right, then add a static route on my ADSL modem for
>>> the return traffic. This is working, but it doesn’t help when trying to
>>> classify traffic by MAC address.
>>>
>>> The only other way I can think to do this is to shape on the internal
>>> interface, eth0. I could classify by IP or MAC address pre-routing, but
>>> that would also mean I’m effectively using IFB for my outgoing Internet
>>> traffic, which is counterintuitive, and I don’t know the implications of
>>> doing it.
>>>
>>> 2)
>>>
>>> Also, it took me a while to test this out, because I was at first
>>> confused by a few rules I had added to firehol a couple days ago for
>>> OpenVPN, which caused my traffic to be classified incorrectly:
>>>
>>> interface tun0 vpn
>>>     server all accept
>>>     client all accept
>>>
>>> router4 internet2vpn inface eth1 outface tun0
>>>     route all accept
>>>
>>> router4 vpn2internet inface tun0 outface eth1
>>>     masquerade
>>>     route all accept
>>>
>>> For some reason, ALL traffic was then masqueraded, even traffic from the
>>> eth0 interface, and not just traffic from the tun0 interface, so my “match
>>> src $ip_address” and “match dst $ip_address” rules weren’t working. Once I
>>> removed those “router4” rules, which I only need in a limited case anyway,
>>> everything was fine again. Is this a bug, or do I not understand something?
>>> (We can start a separate thread on this if that’s better).
>>>
>>> On Aug 17, 2014, at 5:34 PM, Tsaousis, Costa <costa at tsaousis.gr> wrote:
>>>
>>> Hi Phineas,
>>>
>>> I just pushed a version of fireqos that support srcmac and dstmac
>>> parameters.
>>> I cannot test it. I just verified the rules are accepted by the kernel.
>>>
>>> As always you can add multiple MAC addresses in a single parameter,
>>> enclosed in quotes.
>>>
>>> Could you please test it and report back success or failure?
>>>
>>> I generated rules according to http://www.docum.org/faq/cache/62.html
>>>
>>> Thanks.
>>>
>>> Costa
>>>
>>>
>>>
>>> On Sun, Aug 17, 2014 at 3:49 PM, Phineas Gage <phineas919 at gmail.com>
>>> wrote:
>>>
>>>> It would be nice to be able to create a “match” rule in FireQOS to
>>>> match traffic by MAC address.
>>>>
>>>> I’m interested in this because we’ll be transitioning to a dual-stack
>>>> network with both IPv4 and IPv6 support. Currently, we assign IPv4
>>>> addresses using DHCP (some are assigned fixed addresses, and others put
>>>> into different pools), then in fireqos.conf classify using “match src” and
>>>> “match dst” rules with IP addresses. I know this isn’t bulletproof, but
>>>> since I control all of the hosts, it works. With IPv6, we'll get a /64
>>>> address from our ISP, which can’t be subnetted further, and I suppose we’ll
>>>> be using SLAAC instead of DHCP (haven’t sorted that out yet). So, the only
>>>> way I can think of to do traffic classification on a per-host basis is
>>>> using the MAC address.
>>>>
>>>> Anything I’m missing?
>>>>
>>>> _______________________________________________
>>>> Firehol-support mailing list
>>>> Firehol-support at lists.firehol.org
>>>> http://lists.firehol.org/mailman/listinfo/firehol-support
>>>>
>>>
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.firehol.org/pipermail/firehol-support/attachments/20140824/a77cca36/attachment-0001.html>