> 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
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
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
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
> 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
Thanks Brian, I was already filtering that port for traffic outside AMPRnet.
It would not have affected us much because we forward new incoming traffic from internet
only to users who have explicitly requested this. This list now includes 10 /28 subnets
and 29 individual hosts. (189 addresses out of the 65536 address network)
All other users receive new traffic only from 44.0.0.0/8, and replies to their own outgoing traffic.
I added this after the SNMP DDOS incident.... in case there are other problems like this.
Ports filtered here on input from internet are:
135:139,445,1025:1028 TCP and UDP (SMB)
53 TCP and UDP (DNS)
111 UDP (portmap)
161 UDP (SNMP)
1900 (SSDP)
Rob
Can someone please direct me to the right place where I can purchase a
complete kit so that I can setup an IP Ham network system. I would like to
experiment with using using the 44Net as a fall back network in times of
disaster.
Any assistance / direction will be very appreciated as I am new at this.
Thanks
Arnold Villeneuve
www.networkologist.com <http://www.networkologist.com>
Change is the end result of all true learning.- Leo Buscaglia
Thanks Marius. It looks like the instruction are jumbled up a bit to me,
and don't include the creation syntax for the tunnel interface, on the
Wiki. Maybe someone could make an edit to that??
I will try this when I get home later, and see if I can get it to play!!
More to come after that!
--
Rod Ekholm
kc7aad(a)gmail.com
Folks, I have begun blocking the portmapper port (UDP 111) at the UCSD
amprgw gateway. This is to mitigate a new DDOS exploit that is taking
place on the Internet.
This would prevent the use of various RPC services across the
amprgw gateway, but I don't think anyone is currently using NFS,
NIS, or the like in that context. The performance would be very
poor in any case.
You might consider blocking this port in your firewalls.
I recommend that everyone running their own BGP'd subnet insert a
blocking filter rule for this port as well.
More information:
http://blog.level3.com/security/a-new-ddos-reflection-attack-portmapper-an-…
Thanks.
- Brian
Where are you located? Most important (unless you want to build a set of portable nodes that you
can all deploy yourself during an emergency) is to have others to link to. So you need to check what
others are doing in your area, to be compatible with the systems they use.
In the old days, everyone built their own modems and sometimes even radios, and connected them
to general purpose computers running special software.
However, today you can buy ready wireless link and routing equipment from manufacturers like
MikroTik and Ubiquiti for prices much below what we spent on homebrew equipment, and if you wish
you can build an IP network by just plugging those together and do basic routing and linking configuration.
Others have taken existing hardware from Linksys and those same two and replaced the firmware
with own developments that e.g. go beyond the point-to-point linking by offering automatic routing
in a mesh configuration. This may be more convenient in a temporary deployment during an emergency,
but the point-to-point range of such a system is less than with directed links using dish antennas.
Rob
