David et al;
On Mon, 2016-06-06 at 14:46 -0700, David Ranch wrote:
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.
No. I'm at their L4 support group (engineering) and they've been amazed I was able to figure out that their Cisco/Linksys CPEs they're deploying has a crippled firmware as per Comcast's specs. Now that they've been found out they're trying to make a business decision as to put these "features" up as a pay service or open them up for normal usage which would mean a massive upgrade deployment across their network to the end points.
An example of this is their DMZ which -is- on a watchdog timer. It should not be and they even admit that their DMZ is crippled in the units they're deploying - however I also found this appears to be standard Cisco config. These units are also deployed in some of their business circuits so to answer your question it's really a moot issue.
Comcast did inform me that they're NOT filtering ip protocol 4 or any others by nature (except for routing protocols such as BGP/OSPF/etc.) and the "fix" does appear to put their CPE into bridge mode and run your own routing device behind it as I've proved with a DD-WRT router.
As for GRE, years ago we decided to remove it from MFNOS mainly because no one was using it... but then again it'd have been feasible as we were mainly forwarding our encap frames to a central server located within an ISP co-owned by a ham. Back in the day, MFNOS was what we mainly used here in the northeast. Either GRE or IPEncap worked fine in this case.
For the "average to advanced" ham user what we're doing now with policy routing our encap frames is a LOT more efficient coupled with the RIP broadcasts and the portal's ability to refresh any IPs via dynamic hostname resolution however for those on HamWan or a HamNet such a config using IPEncap or GRE isn't necessarily feasible.
Personally, I find it insane to have to use more than one device to handle my incoming IP feed when I'm sure with a matter of some tweeks to the firmware this can all be resolved (Comcast even agrees) for now it's the best solution if you're having issues with them or another ISP who you know isn't filtering IPEncap/protocol 4. I also don't see why this can't be done using a Pi if the device is natting/policy routing/etc too. Just seems like a lot of work when I don't feel it's necessary.
</$.02>