I concur with Bob. I've had Comcast before (though, I always used my own device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've never had success using a consumer-grade router, unless it had DD-WRT or OpenWRT installed, or I used a Linux server. Some D-Link devices permit forwarding of protocols other than TCP/UDP, select the 'Other' option, and place the number 4 in the box for IPENCAP.
Otherwise, most DMZ settings on consumer routers only forward TCP and UDP traffic. Since 44net (including RIP44) packets are encapsulated within IPENCAP (IP Protocol No. 4), you must forward that protocol. The Iptables Firewall is the same as on other *nix devices. If you are NATing to a device inside your LAN, the commands are similar to:
# iptables -t filter -I INPUT -p 4 -i eth0 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -j DNAT --to-destination 192.0.2.8
Ensure that you are in fact seeing IPENCAP traffic entering your Local Network at your device (e.g. the to-destination address specified). Within the IPENCAP packets, you should see the password.
I should also note, that I currently use Verizon FiOS; and I noticed when using their router as my border gateway, that the IPENCAP entry I make is administratively removed (Verizon has a back-door into their routers on tcp/4567) from upstream at intermittent times (I've been told this is because it's 'hard' for the carrier to track and/or rate-limit non TCP/UDP traffic). So be certain that your carrier it not removing firewall entires, especially if you were successful in the past.
73,
- Lynwood KB3VWG
I'm curious if these routers / gateways that block IPIP (protocol 4) traffic might successfully forward GRE (protocol 47)?
GRE is significantly more modern and hopefully, more "allowed" on some of these networks. If it's indeed more "available", I wonder what would be the climate to see if we could get everyone to switch from IPIP to GRE. I imaging that Linux-bsaed systems (and Mikrotik, Cisco, etc) platforms be configured to act as a protocol bridge for any legacy applications running on it. The biggest challenge would be for folks that are using some legacy NOS applications that only support IPIP.
Thoughts?
--David KI6ZHD
On Mon, Jun 06, 2016 at 12:53:46PM -0700, David Ranch wrote:
GRE is significantly more modern and hopefully, more "allowed" on some of these networks. If it's indeed more "available", I wonder what would be the climate to see if we could get everyone to switch from IPIP to GRE. I imaging that Linux-bsaed systems (and Mikrotik, Cisco, etc) platforms be configured to act as a protocol bridge for any legacy applications running on it. The biggest challenge would be for folks that are using some legacy NOS applications that only support IPIP.
AMPRGW cannot support GRE. - Brian
? Ugh... that's not good. I'm curious Brian, beyond being a proven box, is there any other specific reasons to stick with the current ?BSD or Solaris? solution? I can only assume that a properly sized Linux box can equally serve this role and then be on a current OS that could potentially resolve some of the known current limitations of the current AMPRGW gateway.
Just asking..
--David
AMPRGW cannot support GRE. - Brian
On Mon, Jun 06, 2016 at 01:41:31PM -0700, David Ranch wrote:
I can only assume that a properly sized Linux box can equally serve this role and then be on a current OS that could potentially resolve some of the known current limitations of the current AMPRGW gateway.
It probably could, if someone with sufficient Linux knowledge were willing to dedicate the time and effort to doing so. That person is not me.
It would have to be an all-new design as the current router is implemented in user space and uses kernel features of FreeBSD that Linux doesn't have. It wouldn't port. - Brian
Hey Brian,
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.
We, as "power users", have to pick our ISPs wisely for our specific use cases. Unfortunately, that negates us from the higher performance solutions (Cablemodem vs Wirless vs DSL).
--David KI6ZHD
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>
David,
- GRE is a point-to-point protocol. While those using devices that require a single tunnel for each remote gateway wouldn't mind (e.g. Cisco), IPENCAP does not require the host to configure a tunnel for each remote IP address/subnet. (as i recall this setup won't work with AMPRGW)
- GRE would still have to be handled in the same manner (e.g. forwarding '-p 47' instead of '-p 4'). This also have to do this for 6in4, other tunneling, TCP, UDP, etc...as there's a firewall in between. It's not a matter of the protocol, it's a matter of permitting the traffic through the firewall, then NATing it to its Destination.
- KB3VWG
Hello Lynwood,
Interesting point on not requiring a defined point to point configuration for IPENCAP. Though not an ideal setup but I only see 528 entries in the ENCAP file, that's not a huge number of next hops for a sizable Unix host to handle. Ultimately, I *believe* that impacted users getting hosed by changes from their ISP would have more success with GRE than IPIP. This would need to be proven though.
--David
On 06/06/2016 01:38 PM, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________ David,
- GRE is a point-to-point protocol. While those using devices that
require a single tunnel for each remote gateway wouldn't mind (e.g. Cisco), IPENCAP does not require the host to configure a tunnel for each remote IP address/subnet. (as i recall this setup won't work with AMPRGW)
- GRE would still have to be handled in the same manner (e.g.
forwarding '-p 47' instead of '-p 4'). This also have to do this for 6in4, other tunneling, TCP, UDP, etc...as there's a firewall in between. It's not a matter of the protocol, it's a matter of permitting the traffic through the firewall, then NATing it to its Destination.
David,
While that may be the case, I'm not sure you've considered the 527 entries that all 528 AMPRNet admins must then configure on their 528 gateways that comprise AMPRNet...are you certain that all those devices can handle a configuration of 527 individual GRE tunnels???
Also, I don't think it's yet been determined, if the issue the user was having issues due to IPENCAP vs any other protocol. It was my understanding that the user needed to complete some firewall work to allow IP Protocol Number 4 into the network. That task must be completed before one can determine if they're truly not receiving RIP44. Even if GRE is used, then the protocol to firewall simply changes to Number 47.
Also be mindful, some Nations do not permit VPNs or tunneling, so you may have just as much issues with GRE (proto no 47).
- KB3VWG
-----Original Message-----
I only see 528 entries in the ENCAP file, that's not a huge number of next hops for a sizable Unix host to handle. Ultimately, I *believe* that impacted users getting hosed by changes from their ISP would have more success with GRE than IPIP. This would need to be proven though.
--David
David et al;
On Mon, 2016-06-06 at 12:53 -0700, David Ranch wrote:
I'm curious if these routers / gateways that block IPIP (protocol 4) traffic might successfully forward GRE (protocol 47)?
No. In fact they're also filtering OpenVPN. Their illogic is: "we may wish to sell this as an additional service.
So much for Open Internet. Tax dollars failing their own citizens once again *yawn*
On 6/6/16 3:43 PM, lleachii--- via 44Net wrote:
(Please trim inclusions from previous messages) _______________________________________________ I concur with Bob. I've had Comcast before (though, I always used my own device - connecting to a DOCSIS-to-Ethernet bridge/Cable Modem). I've never had success using a consumer-grade router, unless it had DD-WRT or OpenWRT installed, or I used a Linux server. Some D-Link devices permit forwarding of protocols other than TCP/UDP, select the 'Other' option, and place the number 4 in the box for IPENCAP.
Exactly my feelings. When I had a comcast "business" class circuit, the crap-tastic SMC router they gave me would fall on its face constantly and I'd have to hard power it.
Now I have a residential circuit and I went out and bought a $45 modem-only and used a NetBSD box to do my routing and NAT.
Sure beats paying comcast $10/mo for renting crap.
-
Brian -
Brian Kantor -
David Ranch -
James Sharp -
lleachii＠aol.com