[strongSwan] Traffic shaping for multiple ipsec clients with Linux tc

J.Witvliet at mindef.nl J.Witvliet at mindef.nl
Fri Jul 31 13:43:19 CEST 2015


Lartc is the way to go.
Either limit bandwith a-priory, fixed to all possible ip's from the pool, or do it dynamically at connection time.


Verstuurd vanaf mijn iPhone

> Op 31 jul. 2015 om 13:16 heeft Vitaly Repin <vitaly_repin at fsfe.org> het volgende geschreven:
> 
> Hello,
> 
> (I've sent the same question to LARTC and serverfault but there are no
> answers for more than a week.  Looks strange as I thought that my task
> is pretty common. Want to make sure that there is no ready-made
> solution/howto before going to implement my idea)
> 
> I need to divide bandwidth between several clients connected through IPSEC.
> 
> I found this article:
> https://jve.linuxwall.info/blog/index.php?post/2010/10/16/How-can-I-do-traffic-shaping-in-Linux-by-IP
> 
> But my requirements are a little bit more complicated and I need some
> additional advices.
> 
> == How to assign MARK to a new client ==
> 
> 1) I have not the only one, but several clients who are dynamically
> connecting and receiving IPs. How can I assign firewall mark/class
> ids? My current idea is to store mark in the shared memory and
> increment it with every new client.
> 
> Sounds relatively complicated. I can do it, but may be there is a
> simpler solution? Any other ideas are welcome.
> 
> Other approach I am aware of is to make a hash from IP address. In
> this case hash will be 16 bits (range for tc class id)  while IP
> contains 32 bit. Does not look that good.
> 
> == Filters / Classificators ==
> 
> 2) I want to have two classes per VPN client. One for priority traffic
> and another for everything else. I use two marks to achieve this -
> MARKFW_ONE and MARKFW_TWO
> 
> 2.1 SSH traffic: put into priority queue (ssh but NOT scp):
> 
> iptables -t mangle -A INPUT -i $DEV -s $IP -p tcp -m tos --tos 0x10 -j
> CONNMARK --set-mark ${MARKFW_ONE}
> 
> 2.2 ICMP: put into priority queue:
> 
> iptables -t mangle -A INPUT -i $DEV -s $IP -p icmp -j CONNMARK
> --set-mark ${MARKFW_ONE}
> 
> 2.3 To speed up downloads while an upload is going on, put ACK packets
> in priority class:
> 
> iptables -t mangle -A INPUT -i $DEV -s $IP -p tcp --tcp-flags ALL ACK
> -j CONNMARK --set-mark ${MARKFW_ONE}
> 
> 2.4 Everything else:
> 
> iptables -t mangle -A INPUT -i $DEV -s ${IP} -j CONNMARK --set-mark
> ${MARKFW_TWO}
> 
> 
> And at the end:
> 
> # Propagate netfilter marks on connections
> iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark
> 
> Questions are :
> 
> - 2.3: It looks like I am wrong here because this rule shall mark the
> whole connection, not the packet.
>  Shall I simply use -j MARK in this case?
> - 2.2: Shall I replace -j CONNMARK with -j MARK for ICMP case?
> - 2.1 - 2.4. Can I use -j CLASSIFY target instead of marking the
> packets and connections?  I am under impression that I can use it for
> the case 2.2 and   may be 2.3 but NOT in other cases when connection
> shall be marked.
> - 2.1: Is it a proper way to identify ssh traffic (and not scp)?
> 
> Thanks in advance!
> -- 
> WBR & WBW, Vitaly
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users

______________________________________________________________________
Dit bericht kan informatie bevatten die niet voor u is bestemd. Indien u niet de geadresseerde bent of dit bericht abusievelijk aan u is toegezonden, wordt u verzocht dat aan de afzender te melden en het bericht te verwijderen. De Staat aanvaardt geen aansprakelijkheid voor schade, van welke aard ook, die verband houdt met risico's verbonden aan het electronisch verzenden van berichten.

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. The State accepts no liability for damage of any kind resulting from the risks inherent in the electronic transmission of messages.


More information about the Users mailing list