VPN processing delay hit

Home Page Forums Network Management ZeroShell VPN processing delay hit

This topic contains 12 replies, has 0 voices, and was last updated by  nedhead 9 years, 4 months ago.

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #41938

    nedhead
    Member

    I have a vpn link between 2 Soekris 5501-70’s running zsbeta12.
    Link speeds are 4mbs.
    The ping times between the units across the link is around 25ms.
    Just what is expected.
    If I ping devices on each side of the vpn tunnel, I get 46ms if there is little traffic, but get 900-1024 ms if there is traffic (700kbs).
    The cpu’s on each 5501 are running around 96% idle.
    The results are about the same if encryption is on or off.

    I have a bridge to the VPN on each side.

    Did I do something wrong in the setup to incur such a high delay cost ?

    Any advice is appreciated.

    #48801

    ppalias
    Member

    Try to prioritize the icmp traffic in QoS to make sure packets are not delayed.
    Are you definitely sure the tunnel can handle 4Mbps? Could something else utilize the ethernet interface that tunnel goes through?

    #48802

    nedhead
    Member

    The ethernet interface specified for the tunnel only allows the traffic for the vpn tunnel and admin interface traffic – nothing else.

    I have tested the link the vpn uses – and usually get about 3-4 mbs.

    If fact, when I make a change and first bring up the link, the ping times I get are around 40ms – then as traffic over the vpn resumes, the ping times drop to 700-1000 ms.
    Other traffic across this link shows the same effect – poor response to interactive traffic – sluggish response.

    QOS for icmp won’t help everything else. I need to get the packet delays through the vpn down to the 40-50 ms range.

    #48803

    imported_fulvio
    Participant

    Is the VPN compression by LZO enabled? I noticed that compression slow down the VPN bridging.

    Regards
    Fulvio

    #48804

    nedhead
    Member

    I am not using compression. I have even turned off encryption.
    No improvement.

    #48805

    ppalias
    Member

    @nedhead wrote:

    QOS for icmp won’t help everything else. I need to get the packet delays through the vpn down to the 40-50 ms range.

    It looks like either the link capacity is not always 3-4Mbps, or more traffic passes through the vpn tunnel than you think it does.
    As suggested for troubleshooting reason try to apply QoS on icmp and keep pinging. If the problem is fixed, apply QoS on any flow you wish to prioritize.

    #48806

    nedhead
    Member

    I’ll try to put in a network diagram to show the configuration:

    Internet-FW–Net A —SK1


    NetB—SK2—NetC

    Network B is a physical transport for a vpn connection of Net A to Net C.
    SK = soekris 5501 fw’s running zsbeta12. A VPN tunnel has been established between the 2 5501’s, with a bridge on each SK1 to the VPN.
    Traffic is measured by MRTG on the SK’s bridges and found to average 700kbs.
    The routing has been set up so that any internet access on Net C goes to Net A, then out from Net A’s internet access. A download test from a PC on Net C shows a throughput of 2.1mbs. Ping from a pc on Net A to a pc on Net C through the VPN is about 700-1000ms, depending on traffic over the VPN. If there is little traffic on the vpn, this ping test shows about 40ms. A ping from SK1 to SK2 over Net B (therefore not through the vpn tunnel) consistently shows about 20-30 ms (no matter what traffic load over the vpn tunnel) – which is the expected delay through Net B.

    I have to reduce the delay cost of the vpn down to 50ms or so.

    Hope this info helps.

    #48807

    ppalias
    Member

    Apply a QoS on the VPN interface to see if this will increase the response time on your critical applications. It looks like the link capacity is not fully utilized since the physical interfaces communicate with a stable ping.

    #48808

    nedhead
    Member

    I changed my configuration to a routed environment between eth0 (local net interface on both zeroshell firewalls) and vpn00 which talks to the opposite zeroshell firewall. I implemented QOS on routed packets only.
    No improvement!
    Again, pinging eth1 to eth1 (wan interface to wan interface on the zeroshell firewalls), I get 23 ms. Pinging anything through the vpn yields 900-1000ms!
    I appreaciate any other ideas.
    Would it be better to configure the QOS in a bridged network ???
    (eth0 and vpn0 bridged) ?

    #48809

    ppalias
    Member

    Did you apply the QoS on the ETH01 interface or on the VPN00 interface?
    I would suggest to leave the interfaces in routed mode.

    #48810

    nedhead
    Member

    I applied the QOS to the VPN00 interface, not the ETH01 interface.
    I did leave things in routed mode.
    By the traffic shaping graphs, it appears that the QOS is at least seeing the different classes of traffic I set up, but this didn’t help the ping delay at all.
    I had set the icmp in the high priority category, but still am getting 500-1000 ms ping times over the vpn. 😥

    #48811

    ppalias
    Member

    Last but not least try to connect the two boxes back to back with an ethernet cable to have plenty of bandwidth in order to rule out the possibility of a provider issue.

    #48812

    I don’t think this is the issue because if I ping the default router just outside the vpn tunnel on the far end, I get 430ms over the vpn tunnel. If I ping the wan ip on the far end, I get 22 ms.

    #48813

    ppalias
    Member

    Just to make sure.

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

You must be logged in to reply to this topic.