Modify

Opened 8 years ago

Last modified 4 years ago

#7613 reopened defect

multiwan ignores vpn routes without "link" scope

Reported by: potsmaster Owned by: craigc
Priority: normal Milestone: Chaos Calmer 15.05
Component: packages Version: Trunk
Keywords: multiwan vpn Cc:

Description

multiwan copies certain routes from the main routing table into it's private route tables, but ignores routes which do not have "link" scope. These may include routes set up by VPN clients such as openvpn, with the result being that traffic meant for a VPN interface is sent out a WAN interface instead.

The attached patch causes multiwan to also respect routes which have a 'via' attribute.

Attachments (1)

multiwan.diffs (680 bytes) - added by anonymous 8 years ago.

Download all attachments as: .zip

Change History (11)

Changed 8 years ago by anonymous

comment:1 Changed 8 years ago by craigc

  • Owner changed from developers to craigc
  • Status changed from new to assigned

comment:2 Changed 7 years ago by giuseppe <ciusss@…>

Hi,

I have the same problem with multiwan.

comment:3 Changed 7 years ago by jow

  • Resolution set to fixed
  • Status changed from assigned to closed

This seems to be fixed with r22415

comment:4 follow-up: Changed 6 years ago by anonymous

  • Resolution fixed deleted
  • Status changed from closed to reopened

No, it isn't fixed. OpenVPN still doesnt work with multiwan, because vpn traffic tries to go through wan instead of tun0.

comment:5 in reply to: ↑ 4 Changed 6 years ago by ivan

Actually it's working if multiwan is started AFTER openvpn.
So, either use "--route-up and --down" to restart multiwan when the tunnel is upped/downed, or have a script replicating the routes with tunX from the main table to multiwan's tables (170, 171, ...)

comment:6 Changed 6 years ago by Rob

I found that restarting multiwan wasn't really a very good solution as it often caused my VPN connections to reset or drop, and thus never really worked out as expected. (there are also down sides to restarting it as I found it takes time to get itself up and running again properly).

I'm not using OpenVPN, but rather PPTPd... the principle remains the same. What you need to do is make sure that the multiwan load balancing tables are re-synced to the main routing table. I found the easiest way to do this was to add a "forceRefresh" method to the multiwan script that would do the re-sync for you. Then you just have to have your VPN "route up" and "route down" scripts execute it like this:
/usr/bin/multiwan forceRefresh.

I'm no good at making patches, so maybe somebody else wants to take my changes and create a proper patch from them... Just update the multiwan script as follows:
1) Add the following code, anywhere in the main multiwan script (I did it at line 1015)

#Force refresh of routing tables for VPNs, etc
forceRefresh() {
        refresh_routes
        refresh_loadbalancer
}

2) Add the method to call it in the case $1 statement on line 1042

case $1 in
    agent) silencer main_init;;
    stop) silencer stop;;
    forceRefresh) silencer forceRefresh;;
    restart) silencer stop restart;;
    single) silencer stop single;;
esac

3) Now setup your VPN up/down scripts to call it:

/usr/bin/multiwan forceRefresh

Works flawlessly for me...

comment:7 Changed 5 years ago by andee@…

This issue is still present in r34185 attitude adjustment. VPN return packets are send over WAN instead of VPN

comment:8 Changed 4 years ago by anonymous

same problem in BARRIER BREAKER (Bleeding Edge, r40355)

comment:9 Changed 4 years ago by etienne.champetier

comment:10 Changed 4 years ago by jow

  • Milestone changed from Backfire 10.03.2 to Chaos Calmer (trunk)

Milestone Backfire 10.03.2 deleted

Add Comment

Modify Ticket

Action
as reopened .
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.