On 7/16/19 11:28 AM, Holger Baust via 44Net wrote:
> Hi.
>
> My company plans to use DC/OS from Mesosphere and DC/OS is using
> 44.128.0.0/20 per default for overlay networking.
> This seems to have no impact since this overlay nets are only used in
> DC/OS clusters and not routed to the Internet, but might lead to
> problems in some cases...
>
> Their documentation with this informations can be found at:
> https://docs.mesosphere.com/1.10/networking/virtual-networks/ip-per-contain…
You're posting using quoted printable, don't do that. I've fixed your link.
> Is this already known?
News to me, and a really poor idea. There's other networks which could be used
for this, without stepping on allocated space. 44.128.0.0/20 isn't used now,
but neither was 1/8 or 5/8. I kinda want to announce 44.128.0.0/20 just to
mess with them, might freak out if there's a route to that :)
--
Bryan Fields
727-409-1194 - Voice
http://bryanfields.net
On Tue, Jul 16, 2019 at 08:28:49AM -0700, Holger Baust via 44Net wrote:
> Date: Tue, 16 Jul 2019 08:28:49 -0700 (PDT)
> From: Holger Baust <holger(a)dm6hb.de>
> To: 44net(a)mailman.ampr.org
> Subject: Questions regarding usage off 44/8 parts outside of ampr.org
>
> Hi.
>
> My company plans to use DC/OS from Mesosphere and DC/OS is using
> 44.128.0.0/20 per default for overlay networking.
> This seems to have no impact since this overlay nets are only used in
> DC/OS clusters and not routed to the Internet, but might lead to
> problems in some cases...
>
> Their documentation with this informations can be found at:
> https://docs.mesosphere.com/1.10/networking/virtual-networks/ip-per-conta=
> iner/
>
> Is this already known?
>
> 73,
> Holger
While I was unaware of DC/OS specifically using this subnet, I do
know that for many years software from various companies have used
parts of network 44 for "internal-only" networking. In particular,
an obsolete document, which is still available via Google searching
refers to 44.128.0.0/16 in terms which seem to have lead these firms
to believe that it is another RFC1918-style "private network" and
they may use it in that way.
Most of these firms seem to be ignorant of the various RFC1918
networks that are intended for this use. Many of them should be
using the link-local addresses of 169.254.0.0/16, but apparently
don't know about them.
When contacted by me about the misuse of network 44, some are
cooperative and some pull up the obsolete document as justification,
while a small number take up a combative stance and tell me to
contact their lawyers.
Just to make it specific: 44.128.0.0/16 is a subnet currently
reserved for testing in the amprnet. It should not be used outside
Amateur Radio.
- Brian Kantor
Network 44 Manager
On Fri, 2019-07-12 at 14:15 +0000, Ryan O'Connor via 44Net wrote:
>
> Has anyone successfully used AMPRNet with an untangle firewall/router
> device? I’m trying to ditch the Cisco 2850 for something quieter.
>
> Ryan
I don't want to 'jack this thread, but it might be helpful to hear from
others using /any/ of the open source fw/routers available, in particular
anything *BSD-based (I was told a long time ago that "friends don't let
friends run Linux as a firewall).
OSS Platforms that come to mind are pfSense, Untangle, OPNsense, m0n0wall,
smoothwall, etc.
--
Jeff KC9WSJ <jeff(a)kc9wsj.us>
Yes, OPNsense is not one of Vultr’s standard images, but I was successful
in loading a custom ISO of OPNsense on a Vultr server.
I was also successful in getting ZeroTier to work with a customer IP
subnet rather than RFC1918 space.
My next step in to load the dynamic routing missilery in OPNsense and test
originating of a /24 block to Vultr using a private AS number.
If that is successful, then I plan to deploy another OPNsense VM at a
different Vultr data center.
The objective is to have 2 OPNsense gateways, each announcing the same
block to Vultr, and extending that /24 via ZeroTier to our client devices.
If the OPNsense server fails, the BGP announcement will likely also drop,
however the other OPNsense fm in the other data center should pick up the
traffic.
Randy
On Mon, Jul 15, 2019 at 3:51 PM pete M via 44Net <44net(a)mailman.ampr.org>
wrote:
>
>
>
> ---------- Forwarded message ----------
> From: pete M <petem001(a)hotmail.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc:
> Bcc:
> Date: Mon, 15 Jul 2019 22:49:32 +0000
> Subject: RE: [44net] Untangle
> This sound pretty interresting.
>
>
>
> Could this be impremented on a vultur vps?
>
>
>
>
>
>
>
>
>
> ________________________________
> De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la
> part de Randy Neals <randy(a)neals.ca>
> Envoyé : Monday, July 15, 2019 5:04:31 PM
> À : AMPRNet working group
> Objet : Re: [44net] Untangle
>
> I'm currently experimenting with OPNSense on a cloud server, with ZeroTier
> VPN.
>
> I'm intending to run OPNSense on a small i386 device at a repeater site,
> with VPN back to the cloud server.
> Thus extending 44. IP addresses to a variety of radio sites.
>
> Randy, W3RWN
> Seattle.
>
> On Mon, Jul 15, 2019 at 1:42 PM Jeff KC9WSJ <jeff(a)kc9wsj.us> wrote:
>
> > On Fri, 2019-07-12 at 14:15 +0000, Ryan O'Connor via 44Net wrote:
> > >
> > > Has anyone successfully used AMPRNet with an untangle firewall/router
> > > device? I’m trying to ditch the Cisco 2850 for something quieter.
> > >
> > > Ryan
> >
> > I don't want to 'jack this thread, but it might be helpful to hear from
> > others using /any/ of the open source fw/routers available, in particular
> > anything *BSD-based (I was told a long time ago that "friends don't let
> > friends run Linux as a firewall).
> > OSS Platforms that come to mind are pfSense, Untangle, OPNsense,
> m0n0wall,
> > smoothwall, etc.
> >
> > --
> > Jeff KC9WSJ <jeff(a)kc9wsj.us>
> >
> >
> > _________________________________________
> > 44Net mailing list
> > 44Net(a)mailman.ampr.org
> > https://mailman.ampr.org/mailman/listinfo/44net
> >
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
>
>
> ---------- Forwarded message ----------
> From: pete M via 44Net <44net(a)mailman.ampr.org>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Cc: pete M <petem001(a)hotmail.com>
> Bcc:
> Date: Mon, 15 Jul 2019 22:49:32 +0000
> Subject: Re: [44net] Untangle
> _________________________________________
> 44Net mailing list
> 44Net(a)mailman.ampr.org
> https://mailman.ampr.org/mailman/listinfo/44net
>
--
Sent from mobile.
Hello Nate,
>Even in bridge mode I wasn't getting any traffic from AMPRGW. Tomorrow I
>will try bridge mode again, it is possible that I may have set up the
>firewall rules on my edgerouter incorrectly.
I have Comcast Business here to get static IPv4 addresses and it's worth noting that with these cablemodems (a rebadged Cisco DPC3941B), it doesn't support static IPs in bridging. You *must* leave the modem in "Bridge: Off" aka.. NAT mode. In this mode, the inside Ethernet ports or Wifi connections offer both 10.1.0.x NATed address space but also offer my static IP subnet. I infer that for my static addresses, the Comcast box is doing some sort of 1:1 NATing but it does seem to support protocol 4. Externally initiated proto-4 traffic comes in ok so the NATing isn't screwing anything up.
A few more things I recently became aware of from a Comcast support rep if it's helpful to you:
- When enabling or disabling bridging mode, my external IP would get assigned to vastly different subnets. I have no idea why putting the cablemodem into L2 mode would do this but it does. Something worth considering.
- Pseudo mode: It seems that Comcast silently pushes new firmware and does reboots on you. No notifications or release notes are offered up as far as I can tell I noticed the other day that under the bridging configuration area of the cablemodem, it nows shows OFF, Pseudo, ON. I have no idea what this new Pseudo means but it does sound similar to what I described above.
- Uptime: I've been having my cablemodem just stop forwarding traffic after about 70 days of uptime. Working fine and fast one minute, zero packet forwarding after that. The front facing LEDs still look happy, web interface still works, but zero forwarding. According to Comcast, they recommend to their users to reboot the cablemodem every 60 days to avoid issues with memory fragmentation. This is pretty lame if you ask me but this is what they told me and it's something I'm looking to automate if I can find a decent way to automate their web interface (no CLI or API interfaces offered).
--David
KI6ZHD
Has anyone successfully used AMPRNet with an untangle firewall/router device? I’m trying to ditch the Cisco 2850 for something quieter.
Ryan
Sent from my mobile device. Expect strange words and horrendous misspelling.
On Fri, Jul 12, 2019 at 02:27:15AM -0700, Nate Sales via 44Net wrote:
> Date: Fri, 12 Jul 2019 02:27:15 -0700
> From: Nate Sales <nate.wsales(a)gmail.com>
> To: AMPRNet working group <44net(a)mailman.ampr.org>
> Subject: Comcast Xfinity Routing
>
> Hello,
> I'm wondering if anyone here has had success with an IPIP gateway on
> Xfinity by Comcast. I haven't had a lot of success with it, and I'm
> wondering if even in "bridge" mode the CPE modem/router that they give you
> is still blocking protocol 4.
> 73,
> KJ7DMC
Nate:
Whatever your current modem configuration is, it's blocking protocol 4 (IPIP).
Specifically, a traceroute to your gateway, 157.230.161.245 using ordinary
UDP traceroute succeeds. Doing the same thing with protocol 4 (IPIP) gets
a "Protocol Unreachable" ICMP return from your gateway. Viz:
# traceroute -n 157.230.161.245
traceroute to 157.230.161.245 (157.230.161.245), 64 hops max, 40 byte packets
1 169.228.34.82 0.575 ms 0.569 ms 0.561 ms
2 132.239.255.49 0.223 ms 0.206 ms 0.200 ms
3 132.239.254.162 0.247 ms 0.536 ms 0.235 ms
4 132.239.254.149 0.356 ms 0.393 ms 0.265 ms
5 137.164.23.57 2.871 ms 2.841 ms 2.740 ms
6 137.164.22.46 5.335 ms
137.164.11.2 5.129 ms
137.164.22.46 5.165 ms
7 4.35.156.65 4.972 ms 4.911 ms 4.968 ms
8 * * *
9 4.14.33.70 12.617 ms 19.749 ms
4.14.33.54 14.277 ms
10 * * *
11 * * *
12 157.230.161.245 13.960 ms 12.958 ms 14.074 ms
...and...
# traceroute -n -P 4 157.230.161.245
traceroute to 157.230.161.245 (157.230.161.245), 64 hops max, 40 byte packets
1 169.228.34.82 0.613 ms 0.611 ms 0.577 ms
2 132.239.255.49 0.218 ms 0.197 ms 0.215 ms
3 132.239.254.162 0.363 ms 0.227 ms 0.224 ms
4 132.239.254.149 0.364 ms 0.258 ms 0.263 ms
5 137.164.23.57 3.111 ms 3.025 ms 3.108 ms
6 137.164.11.2 5.091 ms 5.122 ms 5.094 ms
7 4.35.156.65 5.219 ms 4.967 ms 4.974 ms
8 * * *
9 4.14.33.70 13.814 ms 13.901 ms 13.844 ms
10 * * *
11 * * *
12 157.230.161.245 14.829 ms !P 14.102 ms !P 13.926 ms !P
- Brian
Nate;
On Fri, 2019-07-12 at 02:27 -0700, Nate Sales via 44Net wrote:
> email message attachment (Comcast Xfinity Routing)
> > I'm wondering if anyone here has had success with an IPIP gateway on
> > Xfinity by Comcast. I haven't had a lot of success with it, and I'm
> > wondering if even in "bridge" mode the CPE modem/router that they give you
> > is still blocking protocol 4.
I'm on Xfinity and it took me about 2 years to figure out what's going
on with them and how to fix it. I wrote a white paper on the topic:
https://uronode.n1uro.com/linux/amprcable.html
It's a 44-net IP so if you can't see it let me know and I'll send you
the text off-list.
--
Rain is caused by big, high-pressure areas; cold fronts; warm, moist air;
And the first day of your vacation.
-----
73 de Brian N1URO
IPv6 Certified
SMTP: n1uro-at-n1uro.ampr.org
Hello,
I'm wondering if anyone here has had success with an IPIP gateway on
Xfinity by Comcast. I haven't had a lot of success with it, and I'm
wondering if even in "bridge" mode the CPE modem/router that they give you
is still blocking protocol 4.
73,
KJ7DMC
