44net

44net@mailman.ampr.org

1 participants
3194 discussions

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> 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

5 4

Suggestions for the portal and the wiki
by Miguel Bahi 07 Jun '16

07 Jun '16

Thanks Brian, for your update. Yes, the Portugese hamnet site is still under construcction. I notice you when this is up and running for update the link. 73’s EB5JEQ Message: 5 Date: Mon, 6 Jun 2016 09:22:08 -0700 From: Brian Kantor <Brian(a)UCSD.Edu> To: AMPRNet working group <44net(a)hamradio.ucsd.edu> Subject: Re: [44net] Suggestions for the portal and the wiki Message-ID: <20160606162208.GA28893(a)UCSD.Edu> Content-Type: text/plain; charset=us-ascii On Mon, Jun 06, 2016 at 02:31:39PM +0200, Miguel Bahi wrote: > Please , I suggest add in this paragraf > http://www.ampr.org/publications/ > add : Spanish hamnet www.hamnet.es I have added the Spanish HAMNET to the list of links on the publications page of www.ampr.org. There is a link on the Spanish hamnet page to the Portuguese hamnet page, but that site is still under construction so I did not add that link to the link list on www.ampr.org. - Brian

1 0

Re: [44net] Unable to Receive rip44 Datagram
by Rob Janssen 07 Jun '16

07 Jun '16

> 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 SSTP is a star as well. In the open world there is OpenVPN over TCP port 443 when you want to run a VPN over TCP (I would not want that, but that is another topic). However what it seems to come down to is that these issues can be solved locally. A local Linux server or (e.g. MikroTik) router can be configured to be part of the IPIP mesh and possibly be BGP routed, and then it can serve as a VPN server for local users using whatever protocol(s) is or are locally preferred due to local situation w.r.t. internet routers and/or filtering. Rob

1 0

Re: [44net] Unable to Receive rip44 Datagram
by lleachii＠aol.com 07 Jun '16

07 Jun '16

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

5 11

Re: [44net] Unable to Receive rip44d Datagram
by Rob Janssen 06 Jun '16

06 Jun '16

> Subject: > Re: [44net] Unable to Receive rip44d Datagram > From: > "Boudewijn (Bob) Tenty" <bobtenty(a)gmail.com> > Date: > 06/06/2016 08:23 PM > > To: > AMPRNet working group <44net(a)hamradio.ucsd.edu> > > > He can check or dd-wrt or OpenWrt firmware is available for his router as these > can forward ipip or can can be set in bridge mode (dd-wrt and OpenWrt are linux based) > and much more. Well, dd-wrt is available for some commercial ethernet/wifi routers but I don't think it exists for any combo-modem-router as is normally used by cable or dsl providers. The dd-wrt people don't have the drivers/software for the modem chips used in those modem-routers. So in this case (a DOCSIS cable provider) it can only be done when he is already using a separate modem and router. > > Some firmwares in these consumer routers even don't allow to be put in bridge mode at > all. The tabs for it are just missing or they don't have an option for it in their menu. Sometimes the ISP can switch the modem-router into modem mode (bridge) from their central management system on user request. It will probably have some strings attached like "no helpdesk support for network problems". After the switchover, the internal ethernet interface will be plain ethernet or PPPoE or PPTP. So you will need an extra router that indeed can be running dd-wrt. However, with today's internet speeds on cable and dsl you also have to consider the router performance. The typical WRT54 routers from the days dd-wrt was created cannot keep up with the internet speeds of today. Rob

1 0

Re: [44net] Unable to Receive rip44d Datagram
by Rob Janssen 06 Jun '16

06 Jun '16

> I have a strong suspicion that my ISP (Charter Communications) has implemented > some kind of filtering on my home cable-based (DOCSIS) internet connection. My > reception of the RIP44d table broadcase has all but ceased. ip-ip tunnel > communication to a friend's machine in a neighboring county only seems to work > for a limited time, and only AFTER I initiate a connection from my end. It's > as if they're using some kind of NAT or port knocking filter, and only opening > the gate for incoming proto 4 traffic for a limited time after I initiate an > outgoing request to a specific host. It is, as Brian N1URO also wrote, an issue in your home router. Other routers have shown this phenomenon for some time. Even when you set a "DMZ" (meaning: forward all unknown traffic to this host), there still is a stateful firewall in place for all protocols except TCP and UDP, requiring you to send outgoing traffic before incoming traffic is accepted. You will need to have the router put in bridge mode (making it only a modem) and install a better router in front of that. With a suitable router, it can also do the IPIP encapsulation. A Linux system of course is a suitable router as well. Rob

2 1

Unable to Receive rip44d Datagram
by kd4cbm＠charter.net 06 Jun '16

06 Jun '16

Good Morning Guys: I have been working to get my chunk of .44 active for a little while now. I've become quite familiar with the concepts of how the network is set up etc. That being said, no matter what I do I cannot seem to get the RIP password that is supposed to be broadcasted from 44.0.0.1. I have go as far as to monitor, log, and filter every packet coming in the cable modem from anything AMPRNet to verify it is arriving. It just seems like the packet is never making it to my public IP. I've gone through all the basics - protocol 4(IPIP) forwarding, UDP port 520 forwarding etc. Like I said, I've even captured all packets pre firewall and I'm not seeing anything AMPRNet. Is it possible that even though my gateway/public IP is registered, the packets aren't being sent out? The last portion of getting this going is that elusive RIP pass. Any suggestions? Thanks, Jason - KD4CBM '73

4 3

disappearing ip alias ?
by Niall Parker 06 Jun '16

06 Jun '16

Has anyone else noted problems with the ethernet alias functionality in recent Linux kernels ? I've just done an update on my tunnel server (pogoplug E02 running Debian 8 with kernel 4.4.0-kirkwood) and within a day or so the 44net alias disappears. Nothing I can see in any of the logs. Replacing the alias via 'ip addr add 44.135.190.17/32 dev eth0:1' is enough to fix it, might have to hack into a cron job :-/ 44 net tunnels are being setup via a script from KB3VNW/LX1DUC, I suspect a few people out there would be using it ... Ideas ? ... Niall

1 0

Suggestions for the portal and the wiki
by Miguel Bahi 06 Jun '16

06 Jun '16

Please , I suggest add in this paragraf http://www.ampr.org/publications/ add : Spanish hamnet www.hamnet.es and for the wiki http://wiki.ampr.org/wiki/Main_Page in the “how to connect to amprnet” title it would be interesting add one easy guide like “ setting up a Jnos Linux gateway” 73’s ------------------------------------------------------ Miguel Bahi Cruz EB5JEQ Amateur Radio Station www.eb5jeq.es ECB03KBQ "galaxia5" CB RADIO STATION Elche Alicante Spain email y skype : miguelbahi_cruz(a)hotmail.com LOCAL VHF : 144.550mhz / UHF : 436.300mhz Echolink: Conference **ESPAÑA** AX25 Packed VHF 144.950mhz AX25mail eb5jeq#ea5dv.eaa.esp.eu APRS chat: 144.800 mhz, monitoring CQ group WWconv ampr.org **Elche_ES** BPQ32net conv **GENERAL** http://www.hamnet.es eb5jeq(a)piserver.eb5jeq.es.ampr.org http://piserver.eb5jeq.es.ampr.org email/forum/wiki/conference XMPP Sysop of EB5JEQ-1:BPQELX AX25 Node BPQnet BPQ32 144.825MHZ EB5JEQ-6:ELXMPR TCPIP Node Ampr.org Net JNOS, 144.825MHZ ( in test ) QRUEB5JEQ Aprs QRUserver ( APRSIS32 ) EB5JEQ-24/ELXNOD24 node HSMM-mesh 2,4 ghz in test EB5JEQ-50/ELXNOD5 nodo HSMM hamnet.es 5 ghz in test

2 1

Re: [44net] Exploitable portmapper service
by Rob Janssen 02 Jun '16

02 Jun '16

> Same here as there is just too much garbage coming in and it is very > labour intensive, I just block it. > Bob Well, here there is a lot more garbage coming in on other ports like 22 and 23 but I don't block that as there might be the occasional user who actually uses it. For the listed completely-blocked ports there appears to be no valid use from internet to amprnet. Internal to amprnet we are a lot more transparent, but at the gateway I do block all traffic to/from addresses without a registration within 44.137.0.0/16. This cuts the noise as well because currently about 2.8% of the addresses is registered. (after the big cleanup) Rob

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net