NetBalancer rules control for UDP packets problem?

Home Page Forums Network Management ZeroShell NetBalancer rules control for UDP packets problem?

This topic contains 1 reply, has 0 voices, and was last updated by  tamws 9 years, 10 months ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #41844

    tamws
    Member

    Dear all,

    Is there a problem for NetBalancer’s Balancing Rules when applying to UDP packets?

    Currently I have a test Zeroshell with two PPPoE WAN interfaces. I wish to control OpenVPN’s traffic to the remote VPN server 192.168.0.9 to route through a dedicated WAN interface ppp0 by modifying the Balancing Rules:

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

    However I found that it only works when I set the OpenVPN to use tcp, if I change it to use the default udp, the traffic is balanced to both WAN interfaces using the default 1:1 rules. That causes 50% packet loss for all the traffic inside VPN! 🙁

    Is there anyone kind enough to give me some advise? Thank you!

    Vincent

    #48573

    tamws
    Member

    Reply to myself:

    I found that if I seperate the Zeroshell into two servers, one handle NetBalancer at the front and the other handle OpenVPN at the back, then the NetBalancer rules can apply for the OpenVPN UDP traffics and the OpenVPN will not have packet loss error anymore!

    It is a bit strange but at least this setup works for me. I wish if there is anyone can tell me why, thank you!

    #48574

    ppalias
    Member

    My suspection is that Balancing Rules are applied to the wrong chain in IPTABLES, than the one they should in order to do your job. If I were you I would try setting up a static route rule that would send IP packets destined to 192.168.0.9 via interface ppp0. That should do it.
    Now if what I say is correct, this is not a bug, as balancing rules should be applied to incoming traffic from the LAN that will be forwarded to the WAN.

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

You must be logged in to reply to this topic.