On Tue, 2016-06-07 at 13:25 -0400, James Sharp wrote:
/I haven't run in to 443 "filtering", but I have run into instances where /> >/the ISP will drop TCP connections that are active for more than a few /> >/minutes, forcing openvpn to restart the connection. /
Chances are your issue is the same as mine was. The CPE (router) has a built in watchdog timer that cuts all sockets after a few minutes. Using port 443 wouldn't make any difference. To the average web user this isn't an issue because each time a page is opened/refreshed a new socket is created, thus a new timer engages. The same may be said for services such as pop3/smtp/etc. where you're engaging a new socket each time you pop or send email. As long as the attachments aren't that big where you may exceed the watchdog's timer you'll never notice this.
So you can never download a file that takes more than a few minutes to complete? Terrible! Now I understand why some companies try to enforce a "download manager" to download a file of a measly 30 MB. So I can continue where I left off, yeah sure.
Well it is clear that everyone should devise their own solution for tunneling and we should not change the global system to cater for limits that certain users encounter. There will always be a more severe limitation found by someone.
It is better to solve these issues locally, where you have fellow users (victims) that can understand what is and what isn't possible.
Colocated (virtual) servers with small storage capacity are very cheap today. Usually they are the entry level of server location, the hoster advertises their $3.99/mo server and knows that "everyone" will upgrade to more storage and pay a lot extra. But for a gateway these are perfectly usable, you can perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with the usual tunl0 and ampr-ripd, and then everyone in the area can make their VPN connection to there. Without NAT problems, and working round nasty ISPs. (you can make a VPN over almost anything if you wish)
Rob
Rob et al;
On Tue, 2016-06-07 at 20:33 +0200, Rob Janssen wrote:
So you can never download a file that takes more than a few minutes to complete? Terrible! Now I understand why some companies try to enforce a "download manager" to download a file of a measly 30 MB. So I can continue where I left off, yeah sure.
It's a shame what they try to hide under the consumer's eyes sometimes.
Well it is clear that everyone should devise their own solution for tunneling and we should not change the global system to cater for limits that certain users encounter. There will always be a more severe limitation found by someone.
Absolutely. In a few cases I've helped others get on 44-net by reverse engineering axudp. It's a hack but works. Just don't try to run anything majorly bandwidth intense over it and you'll be fine.
Colocated (virtual) servers with small storage capacity are very cheap today. Usually they are the entry level of server location, the hoster advertises their $3.99/mo server and knows that "everyone" will upgrade to more storage and pay a lot extra. But for a gateway these are perfectly usable, you can perfectly run it with 512MB RAM and 8GB disk. Put it in the IPIP mesh with the usual tunl0 and ampr-ripd, and then everyone in the area can make their VPN connection to there. Without NAT problems, and working round nasty ISPs. (you can make a VPN over almost anything if you wish)
This also depends on the amount of whitenoise/bot traffic the host is willing to eat and NOT charge you with. I've found here anyway in my little corner of the world if you're flooded out it's your responsibility for having a server online and it'll be your responsibility to pay up for someone else sucking your bandwidth dry - a similar issue I'm against in regards to spam mail eating up one's bandwidth that the individual pays for not the unwanted advertiser.
-
Brian -
Rob Janssen