Ok... all important points to understand and we absolutely rely and appreciate all your help on running the current AMPRGW solution. Before even jumping to conclusion, we'd need to know if GRE really would be more successful than IPIP. In Brian, N1URO's situation, I'm curious if a Comcast "Business" class service would remove some of these intentional filtering issues.
I don't think it will be an appreciable improvement. I have experimented with GRE as the tunneling protocol (chosen exactly for this reason) to connect local stations to our Dutch gateway, and at first the results looked promising, but it did not take long before I got to the first case where plain GRE would not work over a consumer NAT router. I think it is (at least here) never caused by intentional ISP filtering, it is just caused by limitations of NAT routers that were only designed for typical outgoing TCP and UDP connections only. In the mentioned case the router was not even provided by the ISP, making malice even less likely.
I then changed setup to GRE over IPsec which works fine until now when in NAT-T mode, but of course this is only suitable for use in a star configuration with connections initiated from the users to some gateway. Not a replacement for the tunnel mesh.
I heard in Germany L2TP is used, I'm not sure if it is over IPsec or not. Anyway, I use L2TP over IPsec (sometimes over NAT-T) at work, it works over any connection but here as well it is a star topology.
We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter OpenVPN, certainly not when it would be run in TCP mode on port 443.
However, what is common in all these solutions is the star topology where the user behind the crippled router connects outward to a well-connected system.
Of course we don't want to make the entire network into a star, but it could be an idea to deploy more regional gateways like our national gateway, that are interconnected by IPIP tunnels and optionally are BGP-routed on internet, and that offer services like mentioned above and discussed before in this thread to regional users who for some reason cannot run IPIP.
It works well here. It is possible to deploy these on virtual servers that are quite inexpensive these days, certainly when not doing BGP (not all those hosters will offer BGP of a /16 or similar network via their routers, at an affordable price)
In my experience it is possible (although not for "I am not a programmer" types) to get this working well on a Linux box. Setting up the VPN services and routing is quite well described. Setting up a firewall requires some thought and monitoring, see the recent incident with portmap. But this list is available for exchange of such information.
Rob
The situation of GRE on consumer routers is a little more complicated.
Most feature an option like "vpn forward", or "gre forward" or similar. But these forwards work only for PPTP or L2TP, and use port knocking using the PPtP/L2TP control channel to establish the internal forward destination.
That means that, while PPtP or L2TP initiated by a internal client works, plain GRE or other GRE based protocols like EoIP will not.
A possible option could be SSTP, which works over regular TCP connections on port 443. But this is not well supported by the Linux world.
Marius, YO2LOJ
On 6/7/16 4:00 AM, Rob Janssen wrote:
We also offer OpenVPN connectivity at our gateway, in UDP mode only, and this too is problem-free w.r.t. ISP routers. I don't believe a provider would (or even can?) filter OpenVPN, certainly not when it would be run in TCP mode on port 443.
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.
James et al;
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.
I was noticing it when someone asked me to ssh into their system to review their config, tweek their system, etc... and SSH would simply get dropped. When I put the ISP's router into bridge mode and installed a wifi router with DD-WRT, I had found where I was able to disable the watchdog timer and have had no trouble with such things since. Yes it's at the expense of having to use a second device and a little more electricity but for now it's fixed the issues.
You also should be able to receive your RIP broadcasts just fine as well.
I block all ports and only have protocol 4 open. Seems to work for me. Is this reasonable?
Jerry, N0MR
-----Original Message----- From: Brian Sent: Tuesday, June 07, 2016 12:41 PM To: 44net@hamradio.ucsd.edu Subject: Re: [44net] Unable to Receive rip44 Datagram
(Please trim inclusions from previous messages) _______________________________________________ James et al;
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.
I was noticing it when someone asked me to ssh into their system to review their config, tweek their system, etc... and SSH would simply get dropped. When I put the ISP's router into bridge mode and installed a wifi router with DD-WRT, I had found where I was able to disable the watchdog timer and have had no trouble with such things since. Yes it's at the expense of having to use a second device and a little more electricity but for now it's fixed the issues.
You also should be able to receive your RIP broadcasts just fine as well.
-
Brian -
James Sharp -
Lakenet -
marius＠yo2loj.ro -
Rob Janssen