Extremely long routing tables

Scripts with setup, destroy, and modify routing tables and firewall rulesets for client connections.
eliotcougar
OpenVpn Newbie
Posts: 6
Joined: Sat Nov 19, 2016 2:17 pm

Extremely long routing tables

Postby eliotcougar » Sat Nov 19, 2016 2:42 pm

I'm using OpenVPN for circumventing Russian Internet firewall right now using my own server abroad.
In order to do that I've configured some scripts that fetch the list of all blacklisted IPs, merge them into networks where possible, and generate the file with all the route commands for OpenVPN on the server side.
There are some problems with that.
On Windows adding all the 26812 routes (and the number is growing every week) takes very long time, especially on slow computers. It wouldn't be a big problem if OpenVPN started working before adding routes, but it doesn't forward packets until all the routes are set up by Windows. And since OpenVPN does not signal an established connection, it sometimes disconnect it and tries to reconnect before all the routes are added, because some timeout has passed. When it does so, it deletes all the added routes one by one, which is as slow as adding them, and this disconnect-reconnect cycle may repeat endlessly. Right now I have to set connection timeout settings to incredible values (6 hours), and as a result detection of a genuine connection failure that would require a reconnect fails.
If OpenVPN didn't add the specific route yet I see "Website is blacklisted" message from my ISP. If OpenVPN has already added the specific route, but not all routes are added yet, I just see "connection timeout" because OpenVPN doesn't forward packets yet. And only after all the routes are added, it starts working.

Is it possible to make OpenVPN signal connection active before all the routes are added, and make it forward packets while those routes are being added one by one in background? This way I may even be able to prioritize routes in the list, making important/popular ones be added sooner after connection.

ValdikSS
OpenVpn Newbie
Posts: 5
Joined: Thu Sep 24, 2015 10:00 am

Re: Extremely long routing tables

Postby ValdikSS » Sun Nov 20, 2016 9:11 am

Hi. I think you're using antizapret scripts. Several months ago it worked fine, you need to increase keepalive value to 10 mins or more on both server and client:

Code: Select all

keepalive 35 660


Anyway, current antizapret's VPN is pushing only one huge "fake" network (/22) with it's remapping DNS server. If DNS request is done to the blocked domain, remapping DNS server adds iptables NAT translation from fake address to a real A record and returns fake address to the client. This server is not published yet, but if you need it, I can polish and upload it.

eliotcougar
OpenVpn Newbie
Posts: 6
Joined: Sat Nov 19, 2016 2:17 pm

Re: Extremely long routing tables

Postby eliotcougar » Sun Nov 20, 2016 10:43 am

ValdikSS wrote:Hi. I think you're using antizapret scripts.

No, I'm using my own script. It is not automated. I run it on my machine and then transfer the new routes list to my VPS.
Right now I use keepalive 300 21600 because one of my slower machines takes 1.5–2.0 hours to add all routes depending on the CPU load.

Using fake DNS method would mean I'll have to do all DNS requests through this VPN. Maybe I'll do it when my ISP start spoofing Google's DNS...

User avatar
TinCanTech
OpenVPN Protagonist
Posts: 2428
Joined: Fri Jun 03, 2016 1:17 pm

Re: Extremely long routing tables

Postby TinCanTech » Sun Nov 20, 2016 4:58 pm

I think an easier way to achieve your goal is to download a file from the server with all the necessary route information and then process that. It must be done manually or by some other method *outside* of openvpn.

eliotcougar
OpenVpn Newbie
Posts: 6
Joined: Sat Nov 19, 2016 2:17 pm

Re: Extremely long routing tables

Postby eliotcougar » Mon Jan 16, 2017 5:34 pm

I have found the source of the connection problem finally when the route list grew so big the connection took 2+ hours... It turns out that if the TLS renegotiation happens during the process of adding routes twice, the whole connection becomes broken... Ability to communicate with VPN server during the addition of routes would fix this, but for now adding
reneg-sec 86400
tran-window 86400
to both server conf and client conf, is the only thing that makes it possible to establish connection at all... Otherwise it fails to renegotiate new TLS key and loses the stale TLS key too...

Why exactly OpenVPN client cannot route traffic until the whole 40000 routes are added one by one to the windows routing table?..


Return to “Routing and Firewall Scripts”

Who is online

Users browsing this forum: No registered users and 2 guests