I too attempted to get a second TUN interface going for a second VPN connection.
As openVPN is limited to 1 thread and I have a dual core router I was wanting to get 2 running and have some load balancing and some VPN redundancy. I get that one machine won't be able to take advantage of both links for a single connection, however in some scenarios it could use both pipes and other machines would be able to use the extra bandwidth.
I was able to get multiple TUNs up / active and connected to the VPN provider at the same time but i could never get traffic to route properly. meaning that I could send traffic out both individually but nothing would come back on one of the links.
IMHO it’s better to just use a single tunnel instead of 2. Most home routers are not powerful enough to process OpenVPN traffic. You also need CPU time for routing and firewall policing, so it’s best not to tax the router CPU with OpenVPN processing.
I would hazard a guess that bandwidth may drop with 2 load-balanced tunnel running in the same router.
If you really need redundancy, best to use two routers.
IMHO it’s better to just use a single tunnel instead of 2. Most home routers are not powerful enough to process OpenVPN traffic. You also need CPU time for routing and firewall policing, so it’s best not to tax the router CPU with OpenVPN processing.
I would hazard a guess that bandwidth may drop with 2 load-balanced tunnel running in the same router.
If you really need redundancy, best to use two routers.
I am not concerned with load balancing. I am creating two tunnels as I want some ip's routed through ISP, My HTPC running uTorrent through the Netherlands to use PIA port forwarding and the rest through Chicago. The different tunnels are to put the devices in different areas.
Connecting to multiple VPN servers should be considered advance networking IMHO, so yeah, average users should not be trying that, due to complexity in routing.
Default routes can be easily changed using route-up scripts tho, if the server ever pushes it over.
Connecting to multiple VPN servers should be considered advance networking IMHO, so yeah, average users should not be trying that, due to complexity in routing.
Default routes can be easily changed using route-up scripts tho, if the server ever pushes it over.
Are you trying to discourage someone from trying? It is advanced routing, but how do you learn to do this without trying, reading a lot and getting help? You don't just wake up one morning with this ability and say now I know advanced routing and I can try it.
That is what this thread is for. It is for people that do not know advanced routing to read, ask questions and get help from people that do.
I try to give help to users that need it and the more I learn from the people that know, the more I can help the people that don't.
Because of route 0.0.0.0/1 via 10.16.??.?? dev tun1, all the rest of devices are using tun1 also.
The turning point was finding this error in the vpn logs:
Recursive routing detected, drop tun packet to [AF+INET]104.200.???.???:port
then adding option allow-recursive-routing to .conf files
I am trying to figure out how to get the remote address or [AF_INET] for the vpn tunnel. I can pull it from the vpn.log after connection and manually create the route to the wan gateway but I need to find a way to add it to the route-up.sh.
I seen from the manual/google, where using --route-noexec makes this information available to scripts through environmental variable but can not get it to work or even to print the variable $ifconfig_remote from in route-up.sh.
If I bring up both tunnels without the --route-noexec then it sets both remote addresses but it also sets 2 of :
0.0.0.0/1 and 128.0.0.0/1 routes and 1 of each has to be deleted for it to work.
I don't know how both of them are created as I can not create them manually.
As a last resort, I could parse the vpn.log for it but it is not an ideal solution.
Because of route 0.0.0.0/1 via 10.16.??.?? dev tun1, all the rest of devices are using tun1 also.
The turning point was finding this error in the vpn logs:
Recursive routing detected, drop tun packet to [AF+INET]104.200.???.???:port
then adding option allow-recursive-routing to .conf files
Brian
iproute2 may help you.
when connecting to vpn servers, you should use --route-noexec to avoid change of default routes.
Then create multiple routing tables and add default route:
ip r a 0.0.0.0/0 via 10.0.0.1 table 100
This command created a new routing table id=100 if not exists, and add a default gateway 10.0.0.1 in it.
Then use ip rule to route all data from a certain ip (e.g. 192.168.0.1) to routing table 100:
ip ru a from 192.168.0.1 table 100
iproute2 may help you.
when connecting to vpn servers, you should use --route-noexec to avoid change of default routes.
Then create multiple routing tables and add default route:
ip r a 0.0.0.0/0 via 10.0.0.1 table 100
This command created a new routing table id=100 if not exists, and add a default gateway 10.0.0.1 in it.
Then use ip rule to route all data from a certain ip (e.g. 192.168.0.1) to routing table 100:
ip ru a from 192.168.0.1 table 100
* Proper NAT rules may be required.
sorry for my poor English.
I plan to use the --route-noexec on the second tunnel. However when using the noexec it not only dosn't change the default routes, it does not create the route from the tunnels remote address to the wan gateway and the tunnel does not work. I can pull the remote address from the log after connect and add this route but I need to do it in a script. I am trying to figure out how to use environmental variable $ifconfig_remote to create:
ip route add $ifconfig_remote via $(nvram get wan_gateway) dev vlan2
I use:
ip route add default via $(nvram get wan_gateway) dev tun0 table 2
ip rule add from 192.168.3.104 table 2 (one of these for each ip to use tun0)
When you use route-noexec, it doesn't process any route directives in the openvpn config, by design!
Just to clarify, route-noexec doesn't mean just don't change the default gateway. It means don't change or add *any* routes. It just happens that most of the time the only route of interest is the default gateway, and so route-noexec is used. But if you want to *only* prevent the default gateway from being changed, you use the route-nopull directive instead. However, route-nopull has a sometimes unwanted side-effect that route-noexec doesn't. route-nopull won't pull any DNS servers from the openvpn server either.
What few people realize is that when using PBR in the GUI, none of their route directives will be processed, for this very reason. But routes are so rarely added this way, few ppl even notice.
IOW, neither route-noexec nor route-nopull is a perfect solution. And the dd-wrt developers decided to go the route-noexec path for fear of not being able to grab the VPN provider's preferred DNS servers. But the side effect was losing the ability to use route directives.
FWIW, in my own PBR scripts ( https://pastebin.com/u/eibgrad ), I'm keenly aware of this problem and automatically step in to process any route directives I find, even if the GUI and OpenVPN refuse to. You might find those scripts helpful for doing the same thing in your own scripts.
Thanks eibgrad. I will check out your scripts.
I think I found a solution. When not using --route-noexec or --route-nopull, the following routes are added:
remote_address via wan_gateway dev vlan2
10.15.11.1 via 10.15.11.5 dev tun0
0.0.0.0/1 via 10.15.11.5 dev tun0
128.0.0.0/1 via 10.15.11.5 dev tun0
The first 2 need to be added for the tunnel to work and the second should not be added as when the gui creates tun1, it already added them for tun1. So in searching more, I found --pull-filter. I am adding the following lines to .conf:
pull-filter ignore "route 0.0.0.0/1"
pull-filter ignore "route 128.0.0.0/1"
I don't use PBR in the gui and the vpn dns is alreading being pulled when the gui sets up tun1 as the first tunnel.
I will be using table 2 and 3 for PBR adding a default route to wan and tun0 and ip rule to the table.
Once I get this polished, then next step is to get the PIA script to request a forwarding port from tun0 and not tun1 and then use that port to dynamically create a port forward for uTorrent. Then setup the vpn kill switch saying that any packets from 192.168.3.106 bound for wan_gateway (if tun0 down) will be dropped.
The last step will be to write up a how to add a second vpn tunnel using the gui setup as the first. And ideally adding a status>OpenVPN2 tab in the gui to moniter the second vpn tunnel. But 1 step at a time
10.15.11.1 via 10.15.11.5 dev tun0
0.0.0.0/1 via 10.15.11.5 dev tun0
128.0.0.0/1 via 10.15.11.5 dev tun0
Only the first route is needed. That's the route to the VPN. The second two are what I described previously. Those are the overrides of the default gateway. They split the IPv4 address space into two halves and route everything over the VPN. You could just as well delete them and everything would return to the WAN/ISP default gateway, which is what happens when the VPN is brought down.
Remember we are talking about 2 vpn tunnels plus the ISP here, That's 3 routes. Table 2 for ISP, table 3 for tun0, all others tun1. The gui brings up tun1 and adds:
0.0.0.0/1 via ??.??.??.?? dev tun1
128.0.0.0/1 via ??.??.??.?? dev tun1
this is wanted so all traffic not sent to table 2 or 3 go out tun1. I don't want these added when tun0 comes up hence the added:
--pull-filter ignore "route 0.0.0.0/1"
--pull-filter ignore "route 128.0.0.0/1"
The route with the remote tunnel address:
104.200.153.73 via wan_gaeway dev vlan2
seems to be needed as the tunnel does not work without it. Maybe it's the return packets.
I will be testing the added pull-filter lines soon as I need to take down my 2nd vpn connection on the htpc windows client.
Because of route 0.0.0.0/1 via 10.16.??.?? dev tun1, all the rest of devices are using tun1 also.
The turning point was finding this error in the vpn logs:
Recursive routing detected, drop tun packet to [AF+INET]104.200.???.???:port
then adding option allow-recursive-routing to .conf files
Brian
iproute2 may help you.
when connecting to vpn servers, you should use --route-noexec to avoid change of default routes.
Then create multiple routing tables and add default route:
ip r a 0.0.0.0/0 via 10.0.0.1 table 100
This command created a new routing table id=100 if not exists, and add a default gateway 10.0.0.1 in it.
Then use ip rule to route all data from a certain ip (e.g. 192.168.0.1) to routing table 100:
ip ru a from 192.168.0.1 table 100
* Proper NAT rules may be required.
sorry for my poor English.
This is certainly on the right track. But beware. It's not enough to just dump a default gateway pointing to the VPN into a new routing table (100). You have to copy *all* the other non-default routes over as well. Because if you don't, then any client bound to that alternate table will only have the internet as a routing option! And if there are multiple local IP networks (even static routes) established in the main/default routing table, you'll lose communications between them.
The dd-wrt GUI suffers from this very problem. I reported it over a year ago (the bug has always been there, for years) and so far they've refused to fix it.
All this OpenVPN stuff is a lot more complex than most ppl think. Even the developers mess it up from time to time.
I have had the following setup for over a year:
GUI brings up tun1 with no PBR (all devices default here)
table 10 only has "default via wan_gateway dev vlan2"
Wifes pc and 2 bluray players have ip rules:
from 192.168.3.?? table 10
According to what you are saying, my wifes pc being bound to table 10 should only see the wan_gateway(internet). From her pc I can explore other local ip's/pc's, I have not had a problem with this.
I am now just adding a second vpn tunnel to put my HTPC in the Netherlands. After I finish, I will verify that I can browse it from wifes pc(Local ISP) and other pc(vpn chicago).
Because of route 0.0.0.0/1 via 10.16.??.?? dev tun1, all the rest of devices are using tun1 also.
The turning point was finding this error in the vpn logs:
Recursive routing detected, drop tun packet to [AF+INET]104.200.???.???:port
then adding option allow-recursive-routing to .conf files
Brian
iproute2 may help you.
when connecting to vpn servers, you should use --route-noexec to avoid change of default routes.
Then create multiple routing tables and add default route:
ip r a 0.0.0.0/0 via 10.0.0.1 table 100
This command created a new routing table id=100 if not exists, and add a default gateway 10.0.0.1 in it.
Then use ip rule to route all data from a certain ip (e.g. 192.168.0.1) to routing table 100:
ip ru a from 192.168.0.1 table 100
* Proper NAT rules may be required.
sorry for my poor English.
This is certainly on the right track. But beware. It's not enough to just dump a default gateway pointing to the VPN into a new routing table (100). You have to copy *all* the other non-default routes over as well. Because if you don't, then any client bound to that alternate table will only have the internet as a routing option! And if there are multiple local IP networks (even static routes) established in the main/default routing table, you'll lose communications between them.
The dd-wrt GUI suffers from this very problem. I reported it over a year ago (the bug has always been there, for years) and so far they've refused to fix it.
All this OpenVPN stuff is a lot more complex than most ppl think. Even the developers mess it up from time to time.
I have had the following setup for over a year:
GUI brings up tun1 with no PBR (all devices default here)
table 10 only has "default via wan_gateway dev vlan2"
Wifes pc and 2 bluray players have ip rules:
from 192.168.3.?? table 10
According to what you are saying, my wifes pc being bound to table 10 should only see the wan_gateway(internet). From her pc I can explore other local ip's/pc's, I have not had a problem with this.
I am now just adding a second vpn tunnel to put my HTPC in the Netherlands. After I finish, I will verify that I can browse it from wifes pc(Local ISP) and other pc(vpn chicago).
Brian
You can access the hosts in the SAME network, because they are bridged, not routed.
For example, your local ip is 192.168.0.1/24, and you want to access 192.168.0.2, the data has never got routed (in layer 3, Network Layer, or IP) but bridged (in layer 2, Link Layer or MAC). But if you have two local networks, e.g. 192.168.1.0/24 and 192.168.0.0/24, when you try to access 192.168.1.1 from 192.168.0.1, the data will be sent to router and it will be routed. If proper routing rules not exists, your data will lost.
eibgrad is correct. If netns is available, things will be better.
Here's an example. Let's say your primary network is 192.168.1.0/24. And now you add a VAP for the kids to use (192.168.2.0/24) and force anyone on that VAP to use the VPN by placing 192.168.2.0/24 into the PBR field of the GUI. The GUI will respond by creating table 10, install a single route (specifically a default route that points to the VPN), and finally add an ip rule that tells the routing system to use only table 10 for the 192.168.2.0/24 network.
As long as no one on the 192.168.1.0/24 needs to communicates w/ 192.168.2.0/24, or vice versa, no problem. But if either side does attempt to communicate w/ the other, it will FAIL. Those on the 192.168.2.0/24 network only have the internet as a routing option! And that's obviously not going to work in the case of local communications.
The same holds true of any other routes that might exist in the main/default routing table (e.g., static routes). If you don't sync the routing tables (w/ the exception of the default routes), sooner or later you're going to lose communications w/ other networks.
Obviously this isn't a concern if the only IP network you have is the primary one (192.168.1.0/24), and you have no static routes. But since we don't know the full scope of your dd-wrt configuration, it's only prudent to warn about this potential problem.
Isn't the whole point in putting them on separate subnets to keep them from talking(security)? Otherwise why separate them?
Update:
I have had 2 tunnels (tun0 and tun1) up and running stable for 2 days now.
Tun1 comes up from the GUI and tun0 is brought up from a script run from startup so it's all animated. Soon I will write up a how to.
Brian
Tun0 and Tun1 running stable. Next thing to address is route-down script. Making it remove the custom routes/rules I added in route-up(Tun remote address to wan and ip rules). Then setting up a proper watchdog for my second tunnel the way the GUI handles it's tunnel.
