44net

44net@mailman.ampr.org

2 participants
3201 discussions

Start a nNew thread

44/8 routing problem at UCSD
by Brian Kantor 23 Jun '16

23 Jun '16

There appears to be a routing problem with the path to the amprgw router at UCSD. I'm investigating. - Brian

3 3

Help setting up a BSD-based gateway?
by Dan Cross 18 Jun '16

18 Jun '16

Dear Folks, I'm trying to set up an AMPRnet gateway at home and am running into some problems. Has anyone successfully configured a BSD-based gateway that would be willing to give me some pointers? Some details of my setup: * I have a comcast business-class circuit with a static IP address that I've dedicated to 44net traffic (23.30.150.141). * I have an AMPRnet network allocation (44.44.107.0/24). * The Comcast router is configured as simply a router: all NATing and firewalling is disabled and I can see tunneled traffic arriving at the external NIC of my (non-comcast) router (specifically, I see RIPv2 packets with 44net routing information in them). * My "real" router is a Ubiquiti EdgeRouter Lite running OpenBSD 5.9. I have the three ethernet interfaces on the ERL configured as follows: cnmac0: flags=8b43<UP,BROADCAST,RUNNING,PROMISC,ALLMULTI,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:64 priority: 0 groups: egress media: Ethernet autoselect (1000baseT full-duplex) status: active inet 23.30.150.141 netmask 0xfffffff8 broadcast 23.30.150.143 cnmac1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:65 priority: 0 media: Ethernet autoselect (1000baseT full-duplex) status: active inet 192.168.129.4 netmask 0xffffff00 broadcast 192.168.129.255 cnmac2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500 lladdr 44:d9:e7:9f:a7:66 priority: 0 media: Ethernet autoselect (none) status: no carrier inet 44.44.107.1 netmask 0xffffff00 broadcast 44.44.107.255 Where I'm getting tripped up is in figuring out where to go from here. It seems like what I want to do is configure a gif(4) interface for tunnel traffic, but my attempts at doing so all seem to fail, and documentation for setting up an IPENCAP tunnel is related to setting up IPsec gateways; my attempts at transliterating from the examples for e.g. Linux and Cisco et al have failed. If someone has gone down this road before and has a working setup, that would be tremendously helpful. If someone could send me output from 'ifconfig -a' and/or 'netstat -rn -f inet' and possibly some 'tcpdump' output, I could probably muddle through the rest. If there are any caveats in setting up a 'pf' based firewall, that would be helpful as well. If not, I suppose my next step will be to reinstall RouterOS on the ERL, try and get everything configured, and then see if I can replicate under BSD. Much thanks in advance! 73 de AC2OI, - Dan C.

7 18

Re: [44net] disappearing ip alias ?
by Rob Janssen 17 Jun '16

17 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 :-/R Why are you still using ethernet aliases? This was originally a hack to be able to have multiple IP addresses on a single interface (using ifconfig) but since the introduction of the iproute2 package (which you apparently use, as it provides the "ip" command) this is really not required anymore. You can add addresses to eth0 without making an eth0:1 alias first. Rob

3 3

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> In any case, your subnet will be connected to the Internet by at most > ONE method: Radio, Tunnel, or Direct, and might not be connected at all, > so select at most ONE of the connection method boxes in the allocation > request. (I have asked that these selections be changed to a pulldown > list or radio buttons so that it is impossible to select more than one; > until that happens, requests having more than one box checked are likely > to be rejected.) > - Brian Why is that?? We have been happily connected on both BGP and Tunnel for some time. The gateways that are part of the tunnel mesh route to us by Tunnel and the remainder of internet routes directly. What is wrong with that? Some gateways do not want to route directly ("only AMPRnet") so it is preferred when they can use the Tunnel to the same network. Rob

8 9

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> The idea here is to support IPIP and BGP concurrently while preferring IPIP. Additionally we also > run BGP over other tunnel protocols ( GRE, SSTP, etc) with more specific preferences depending on the > agreement between the Ops. AFAICT this setup is the only way wich allows both the IPIP-only and the BGP-only > sites to reach our networks. > vy 73 de Marc, LX1DUC I agree, that is the way it works best. We do that here as well, however now we just have a single routing table where routes of different origin are stored at a different metric, so there is no fixed priority between protocols anymore. The first decision is always made on subnet size (smaller subnet has preference), the metric only comes into play when for some reason there are routes over two different protocols for the same subnet, and then the metric decides what path to take (e.g. there is both an IPIP tunnel and a a route announced with internal BGP on HAMNET). Normally these are error conditions. The difference between those methods becomes important when e.g. a /20 subnet is IPIP tunneled and out of that a /28 subnet is routed another way, e.g. over a GRE tunnel. This works without problem for us now. (on systems that are both on the normal internet and on the IPIP mesh reachable from the entire internet, with source address filtering at the provider, I normally have at least two different routing tables and policy routing, but on a directly routed system this is not required) Rob

1 0

Re: [44net] block allocation
by Rob Janssen 16 Jun '16

16 Jun '16

> On Wed, Jun 15, 2016 at 11:46:30PM +0200, Rob Janssen wrote: > >/A quick check returns the following subnets being both BGP and Tunnel routed: / > I stand corrected. > - Brian Well, before I made that list I hoped that it would be much longer... Maybe I made a mistake, it was quick cut-and-paste followed by edit and comm of the list of bgp routed subnets and the routes in my personal gateway. Anyone with a BGP subnet who has a full-featured system as a router should consider to announce the same subnet on the IPIP mesh, I think. (with a tunnel endpoint address outside net-44, certainly outside the subnet) Rob

1 0

Re: [44net] block allocation
by Rob Janssen 15 Jun '16

15 Jun '16

> I'm not saying you can't be connected in more than one way, I'm saying > that it's a special case that is unusual enough that it ought not to be > easy to mistakenly claim you're going to do. As far as I know, Rob, at > the current moment you're the only one doing this. Hmm... disappointing. I would hope everyone who is BGP routing would be doing that. I am not the only one, your gateway is doing the same thing :-) A quick check returns the following subnets being both BGP and Tunnel routed: 44.135.193.0/24 44.136.227.0/24 44.137.0.0/16 44.161.230.0/24 44.161.252.0/22 44.188.128.0/20 44.208.0.0/16 44.48.16.0/24 > Two or three times a week I get applications which have simplemindedly > checked all three boxes. Most of these people have no idea what they're > asking for Most applications of portal registrations I get are wrong or strange. It appears that the thing is confusing to newcomers. > I'm open to any suggestion that will keep me from having to go through > this process over and over again. Perhaps making 'Direct' a link which > brings up an intermediate page which presents a blurb about what checking > Direct actually means and demands that they confirm that they're really > going to get a BGP announcement from their ISP? Other ideas? It could be done with a simple Javascript on the page that presents a pop-up or reveals some explanation on the page when the checkmark is set ON.

3 2

block allocation
by Pierre-Philippe F4MZI 15 Jun '16

15 Jun '16

Hi there, I actually have a /32 IP. I plan to connect a few new machines to the network. So, I would need 3 or 4 new adresses. I went to the web page, the the network tab, and click on 44.0.0.0 / 8 <https://portal.ampr.org/networks.php?a=request&id=1> Global link. the smallest block that I can request through this link is a /24. but I don't need a /24, only a /29 how can I send my request directly from the web site ? thank you -- 73, Pierre-Philippe F4MZI

3 11

Re: [44net] block allocation
by Rob Janssen 15 Jun '16

15 Jun '16

> Subject: > Re: [44net] block allocation > From: > "Bill Buhler - AF7SJ" <af7sj(a)buhlerfamily.org> > Date: > 06/15/2016 06:47 PM > > To: > "'AMPRNet working group'" <44net(a)hamradio.ucsd.edu> > > > > Sorry if I'm unclear, so what I'm envisioning is setting up tunnels to the > other participants of the 44 net who aren't directly internet routed and > using RIP advertisement for them. Then traffic between me and them can > bypass the main AMPR 44 net router, reducing latency and reducing bandwidth > requirements at the root node. > > In other words, if anyone on my subnets access the internet it would route > through our BGP connected uplink. If they were communicating with another > subnet on the AMPRNet it would tunnel directly to them. > > What do you think? > > Bill Buhler > AF7SJ > Indeed that is how we route here as well. Please don't remove that from the Portal! Rob

1 0

Re: [44net] Help MBOX flood
by lleachii＠aol.com 15 Jun '16

15 Jun '16

Pedro, I use the following iptables rules on my router (this will work for any console-based connection using TCP): # DROPS MULTIPLE SSH CONNECTIONS FROM SAME IP iptables -t filter -I FORWARD -p tcp --syn --dport 22 -i tunl0 -m connlimit --connlimit-above 5 -j DROP # DROPS MULTIPLE SSH ATTEMPTS FROM SAME IP WITHIN FIVE MINUTES iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state --state NEW -m recent --name sshconnect --update --seconds 300 --hitcount 5 -j DROP iptables -t filter -I FORWARD -p tcp --dport 22 -i tunl0 -m state --state NEW -m recent --name sshconnect --set The first rule drops any connections greater then five. The last two rules mark and drop more than five attempts from the same IP, for a period of five minutes. You may wish to increase the time frame. I've also added rules to block IPs that attempt to connect (or portscan) on certain TCP and UDP ports (3389/tcp, 123/udp and 161/udp are common, for example) for which I not post services as available to the AMPR Community or the Public Internet connection. In essence, even if an unauthorized person discovered the the port without being firewalled by the portscan rule, they only get 5 chances, with up to 5 concurrent connections at any given 5 minute interval (the amount of attempts vary by implementation of server and client; but once portscanned or disconnected from a given series of attempts, it counts at one connection). Each reattempt after 5, restarts the 5 minute clock. I also block Bogon IP addresses from entering tunl0: # DROPS BOGONS ENTERING AMPRNet # SEE http://www.team-cymru.org/Services/Bogons/bogon-bn-nonagg.txt iptables -t raw -I PREROUTING -s 0.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 10.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 100.64.0.0/10 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 127.0.0.0/8 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 169.254.0.0/16 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 172.16.0.0/12 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.0.0.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.0.2.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 192.168.0.0/16 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 198.18.0.0/15 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 198.51.100.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 203.0.113.0/24 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 224.0.0.0/4 -i tunl0 -j DROP iptables -t raw -I PREROUTING -s 240.0.0.0/4 -i tunl0 -j DROP I should note that in addition to this, console-based connections that I use for administration only are moved to non-standard ports. So I added another layer of protection with Security Through Obscurity (hence a portscan rule). 73, Lynwood KB3VWG

3 4

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net