QoS when zeroshell using lan-2-lan vpn

Home Page Forums Network Management ZeroShell QoS when zeroshell using lan-2-lan vpn

This topic contains 13 replies, has 0 voices, and was last updated by  jasonh100 8 years, 10 months ago.

Viewing 15 posts - 1 through 15 (of 15 total)
  • Author
    Posts
  • #42215

    jasonh100
    Member

    I have created a lan 2 lan vpn between two zeroshell boxes at two different locations. The zeroshell boxes also have eth0 and eth1 bridged together to act as a transparent QoS bridge.

    I am familiar with zeroshell qos and I’m typically able to classify traffic successfully but the classifiers that I have set up to capture the vpn traffic are not successful. I have even set up a blank classifier that should catch everything. It catches everything but the vpn traffic. The vpn traffic is sent to the DEFAULT classification on eth00 and eth01.

    The vpn traffic is only used for voip between two offices. Each office will also have a voip connection through the internet to a sip trunking service. Therefore my goal is to have internet traffic sent to the sip trunking service and vpn traffic classified into the same class. Since I was not able to classify any of the vpn traffic, I decided to try and work backwards by creating my own classification for all traffic that was not previously matched by other rules so that it could go into my own ‘default” class. Then I could make the built-in default class a high priority. This idea seems convoluted, but unfortunately I don’t think it will work because I want to leave the bandwidth (max and guaranteed) blank on the default class given that the downstream bandwidth and upstream bandwidth of the internet connection both share that class so there is not a single value that I can correctly specify there.

    Thanks for your hlep

    #49673

    jasonh100
    Member

    While I would still like to know if it is possible to do this in a more correct way… I realized an answer for my problem right at the end of typing this. Since the vpn is used just for voip and voip uses the same outgoing and incoming bandwidth (approximately), it will be fine to put a max and guaranteed bandwidth on the DEFAULT class (which is automatically placed for eth0 and eth1)

    #49674

    ppalias
    Member

    I am not sure what your question is here. Could you order the things a little bit?

    #49675

    jasonh100
    Member

    Hi, sure, I will re-clarify what I’m asking. Btw, I was looking back at this post again because I came upon a reason to need to know how to solve this correctly.

    For the sake of normalcy, we’ll just say that I have two zeroshell systems with two network cards each.

    Lets say eth0 is connected to the lan at each site and eth1 is connected to the internet with an internet ip address (12mbps down/ 768kbps up)

    Then, lets say that I have created a zeroshell lan-2-lan vpn connection between the two sites through the internet connections.

    My primary goal is to add QoS shaping on the upload side (768kbps) of the internet connection.

    My secondary goal is to add QoS policing on the download aspect (12mbps) of the internet connection.

    To do this, I enabled qos on the eth0 interface on the zeroshell machines. I am able to create classes and classifiers and successfully shape/police normal internet traffic.

    The problem is that I completely unable to classify vpn traffic. Even if I add a blank classifier that should catch everything it catches everything BUT vpn traffic.

    My original solution to classify vpn traffic was to classify EVERYTHING else and assume set up the default class based on the assumption that anything that goes to the default is vpn traffic.

    The problem with that solution is that now I’m setting up a similar system where the vpn will have two types of traffic on it so I need to be able to classify the two types of traffic independently. Basically I really need a way to classify and shape vpn traffic.

    So, here is another variable to add into the mix — when relying on classifying the vpn based on the default traffic, you run into a problem with internet connections that have a different upload vs. download speed. As soon as you put a speed to the default class you are basically limiting the upload and the download to being the same speed for the default.

    Basically, since I’m obviously lacking the necessary experience to properly configure this, I’m open for suggestions.

    Thanks so much!

    #49676

    ppalias
    Member

    You only need to apply QoS on ETH01 interface, which is the WAN.
    traffic in VPN has to be matched on interface VPN00, not on ETH01. On ETH01 you need to classify the traffic of UDP/1194 which is the VPN itself. If you need more help paste here a screenshot of your config.

    #49677

    jasonh100
    Member

    Thank you for the feedback. My problem is that I’m not able to classify the vpn traffic on eth01. I can classify any other internet traffic successfully. When I apply the rule udp/[vpn port number] as you suggested to capture the encrypted vpn traffic, it does not classify it. Strangely a blank rule that should classify all traffic classifies all traffic but vpn traffic. The vpn traffic still ends up in the default class. I haven’t tried to sub-classify the vpn traffic yet, but I suspect that it will work normally. I first need to be able to classify the vpn traffic successfully on eth01 where it is competing with all other internet traffic.

    I will set up a new test platform and I will post screenshots of the inability to classify vpn traffic on eth0 — or I will post screen shots of me looking stupid and wasting your time 😉

    #49678

    jasonh100
    Member

    Sorry, for the trouble, but there are a lot of screenshots that would be needed to prove that I’m not able to classify the vpn traffic. For the test I just did, I’m just using eth0. Eth0 is assigned a local ip and is plugged into a switch. an internet router forwards the vpn ports to the zeroshell local ip and that is how I have the vpn up and running. I enabled qos on eth0, I added a class called “VPN_OUT” which I gave 20kbps max and guaranteed bandwidth; I added the class to the eth0 interface, I activated the changes, I added the following classifier to mark all traffic as vpn_out:

    MARK all opt — in * out * 0.0.0.0/0 -> 0.0.0.0/0 MARK set 0xb

    I saved the classifier

    Then I used ssh to connect through the vpn to a host on the other side of the vpn. Then I used sftp to connect back to a host on my side of the vpn to download a file (which would be uploading a file as far as my local vpn is concerned).

    The rate of file upload was around 60KB/sec (480kbps). I would expect the transfer speed to be less than 20kbps given the overhead of the vpn would be taking up some of the 20kbps that is available.

    I checked the statistics for the QoS. A minute amount of packets was adding up on vpn_out (which should be classifying everything). I refershed a couple of zeroshell web interface pages to see if they were contributing — they were not (strangely).

    So I checked the download speed through the vpn (which should also be classified by the above rule). The download speed was “policed” down to less than the 20kbps mark. This is what I mean when I say “policed”: The way I understand it, it is more normal to impliment qos on the outbound because that is what you control, but you can also police inbound traffic. Basically, you just drop the packets that go above and beyond your limit. The sending host does not receive ACKs to some of the packets that were dropped so it knows to resend and also to slow down. Messy but effective.

    Any suggestions based on this additional information? has anyone been able to effectively classify lan-2-lan vpn traffic with zeroshell?

    #49679

    ppalias
    Member

    I have 2 gateways on my ZS, so QoS is not working due to a known bug. However I classify vpn traffic at the Netbalancer so that all traffic goes out the gateway I want.

     pkts bytes target     prot opt in     out     source               destination
    122M 14G MARK tcp -- !BRIDGE00 any anywhere anywhere tcp spt:1194 MARK set 0x66

    BRIDGE00 is my internal network.

    #49680

    jasonh100
    Member

    how would that provide qos for your vpn traffic unless you had a dedicated default gateway that only handled your vpn traffic?

    Or is your point simply that you are able to classify the vpn traffic through a net-balancer rule?

    Any idea why I’m not able to classify outgoing vpn traffic with a QoS rule?

    If I’m not connecting the dots and there is some way that I can use balancing rules to provide the same effect as qos, please elaborate.

    Thanks,
    Jason

    #49681

    ppalias
    Member

    This rule is to show you how I match VPN traffic. I mentioned that I don’t apply it on QoS, I apply it on Netbalancer instead.
    If you need more help you’ll have to provide more info, like screenshots or command outputs.

    #49682

    atheling
    Member

    Tangential to the original query but since you are trying to do VoIP this might be of interest…

    Near as I can tell, Zeroshell uses TCP for the transport on its OpenVPN configuration. TCP is not a good transport for VoIP for a number of reasons so you probably won’t be happy with your VoIP call quality even if you get the QoS working the way you want.

    #49683

    jasonh100
    Member

    atheling, I have the lan-2-lan openvpn connections setup using the UDP protocol and not the TCP protocol. When setting up a VPN for voip only using zeroshell, I was (with a little outside of the box thinking) able to successfully configure internet qos to make sure that vpn traffic would have a high priority by classifying “everything else” as needed, setting a guaranteed and max speed on the default class, and setting the priority of the default class to highest. The vpn qos works as necessary for voip — i.e. uploads do not interfere with voice call quality, excessive downloads do not interfere with voice call quality (if policing is used as well–normally mild downloading would not interfere given the proportionally large download speed that is commonly available)

    ppalias, thank you for your help. I greatly appreciate all the time that you have spent helping me with this. I made most of the screenshots, but it seems difficult to believe/convey the fact that a rule that should classify Everything is classifying Everything BUT the vpn traffic with just a screenshot.

    Anyway, here is my attempt:

    Please see this screen shot:

    http://picasaweb.google.com/102368343210452599606/Zeroshell?authkey=Gv1sRgCO-nv9-W_s2VcQ#5454903833139369122

    As you can see from the shot, despite the classifier that should classify all traffic to the VPN_OUT class, only a minute amount of traffic is classified into that class. Everything else goes to the default class. There is no other traffic on the zeroshell box except for vpn (it is strictly configured as a vpn gateway). This leaves me to assume that practically everything that goes into the default class is vpn related.

    Please note, you would probably say that if the zeroshell is not the default gateway for the internet, there is no reason to shape traffic. This is a simplified test case. The same symptoms would be seen in a situation where the zeroshell box had a pppoe connection directly connected or if the box was set up to be a transparent qos bridge.

    Thanks!

    #49684

    ppalias
    Member

    There is always a reason to use QoS when you leave a high speed network to a slower one. The only excuse I can guess is either that since you have consumed the maximum outgoing bandwidth, the rest of the traffic goes to the default class, or something is wrong with the web interface. Could you paste here the output of

    iptables -t mangle -L -v
    iptables -t nat -L -v
    tc -s qdisc
    #49685

    jasonh100
    Member
    root@zeroshell root> iptables -t mangle -L -v
    Chain PREROUTING (policy ACCEPT 14M packets, 1302M bytes)
    pkts bytes target prot opt in out source destination

    Chain INPUT (policy ACCEPT 13M packets, 1132M bytes)
    pkts bytes target prot opt in out source destination

    Chain FORWARD (policy ACCEPT 695K packets, 166M bytes)
    pkts bytes target prot opt in out source destination
    390 147K MARK all -- any any anywhere anywhere MARK set 0xb
    390 147K ACCEPT all -- any any anywhere anywhere MARK match !0x0

    Chain OUTPUT (policy ACCEPT 14M packets, 1105M bytes)
    pkts bytes target prot opt in out source destination

    Chain POSTROUTING (policy ACCEPT 15M packets, 1275M bytes)
    pkts bytes target prot opt in out source destination

    Chain NB_CT_POST (0 references)
    pkts bytes target prot opt in out source destination
    0 0 CONNMARK all -- any any anywhere anywhere CONNMARK save

    Chain NB_STAT (0 references)
    pkts bytes target prot opt in out source destination

    Chain NetBalancer (0 references)
    pkts bytes target prot opt in out source destination

    Chain OpenVPN (0 references)
    pkts bytes target prot opt in out source destination
    root@zeroshell root> iptables -t nat -L -v
    Chain PREROUTING (policy ACCEPT 32429 packets, 5385K bytes)
    pkts bytes target prot opt in out source destination

    Chain POSTROUTING (policy ACCEPT 585K packets, 36M bytes)
    pkts bytes target prot opt in out source destination
    585K 36M SNATVS all -- any any anywhere anywhere

    Chain OUTPUT (policy ACCEPT 577K packets, 35M bytes)
    pkts bytes target prot opt in out source destination

    Chain SNATVS (1 references)
    pkts bytes target prot opt in out source destination
    root@zeroshell root> tc -s qdisc
    qdisc htb 1: dev ETH00 root r2q 10 default 10 direct_packets_stat 0
    Sent 52545035 bytes 479553 pkt (dropped 0, overlimits 6834 requeues 0)
    rate 0bit 0pps backlog 0b 0p requeues 0
    qdisc sfq 10: dev ETH00 parent 1:10 limit 127p quantum 1514b perturb 10sec
    Sent 50248672 bytes 474662 pkt (dropped 0, overlimits 0 requeues 0)
    rate 0bit 0pps backlog 0b 0p requeues 0
    qdisc sfq 11: dev ETH00 parent 1:11 limit 127p quantum 1514b perturb 10sec
    Sent 2296363 bytes 4891 pkt (dropped 0, overlimits 0 requeues 0)
    rate 0bit 0pps backlog 0b 0p requeues 0
    qdisc pfifo_fast 0: dev ETH01 root bands 3 priomap 1 2 2 2 1 2 0 0 1 1 1 1 1 1 1 1
    Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
    rate 0bit 0pps backlog 0b 0p requeues 0
    qdisc htb 1: dev VPN00 root r2q 10 default 10 direct_packets_stat 0
    Sent 889194 bytes 3457 pkt (dropped 0, overlimits 0 requeues 0)
    rate 0bit 0pps backlog 0b 0p requeues 0
    qdisc sfq 10: dev VPN00 parent 1:10 limit 127p quantum 1514b perturb 10sec
    Sent 889194 bytes 3457 pkt (dropped 0, overlimits 0 requeues 0)
    rate 0bit 0pps backlog 0b 0p requeues 0
    #49686

    ppalias
    Member

    Can’t think of something… I will take advantage of my easter vacation to read more carefully the LARTC. Happy easter everyone!

Viewing 15 posts - 1 through 15 (of 15 total)

You must be logged in to reply to this topic.