Hello Lynwood;

As the author of such I'll try to answer your concerns.

On Sat, 2016-08-20 at 19:39 -0400, lleachii--- via 44Net wrote:

I agree about the security concerns, etc. But in some uses of IP, it would be very difficult to provide services to multiple devices over NAT technology (e.g. allowing multiple servers needing the same TCP or UDP port or IP protocol number, providing an adjacent private network the option to route to the host via direct connection or over the Global Internet). Also, the reason supporting the statement is quite inaccurate. A large majority of ISPs not yet implementing Carrier Grade NAT, do in fact, assign the end user pubically routable IPv4 space. Granted, it's commonly a single /32 IP address. The page actually goes on to describe the need of IPs according to the same principal - which is basically today's standard practice.

You're reading too deeply into for whom the page was written for. There's no mention at all about security configurations nor NAT. It's drafted for the most novice of users, not those who have a good understanding about the protocols we use. I think while you were reading it, you were injecting your own interpretations of things that don't exist in the page.

The comment regarding 802.11 devices (or any IP routing device for that case) is somewhat dubious security-wise ("this would not include any 802.11 routers for use on /HamWan/HamNet/ as doing so would make you quite insecure."). Archives of security comments in this forum from others suggest proper firewalling is necessary in environments running IPENCAP-enabled routers, ESPECIALLY BECAUSE of the presence of NAT/masquerade co-existing in some AMPRNet nodes. It can only be assumed from the Wiki that the Ham allocated the IP space ensures or guarantees firewalling by using NAT. While NAT has security benefits, it was invented with an affect of slowing IPv4 exhaustion. In our IPENCAP environment, it is a vector to send IP datagrams to "this network" (i.e. how your router perceives 0.0.0.0/0), AMPRGW, other gateways, or an adjacent private network (e.g. your home/corporate/government LAN). For this reason, the OpenWRT router setup page includes information regarding configuration of a basic Virtual Routing and Forwarding environment on your Linux-based router. This configuration places any AMPR interface on a separate, routing table not possessing locations of non-AMPR subnets (i.e. routing table "44"). While I'm not certain if any node in the /HamWan/HamNet/ networks run IPENCAP, others in AMPRNet do.

I think you're injecting terms that don't exist on the page and are trying to squeeze them in where a novice would be greatly confused. As you know, once you decode the incoming IPEncap frames into your lan, you no longer need to continue routing those frames via IPEncap and you can easily push routes via RFC-1918 space internally within your lan. Also one who's running BGP would have a totally different configuration than that you suggest and would not be running IPEncap. While ISPs may give end users a single /32 IPv4 IP, their backbones aren't necessarily public IPs. With most of the ISPs I've been with, we've used 10-net space with the routers we interconnect within our intranet network with various border routers having public IPs to our peers. If this didn't work, we'd have had an excessive amount of very upset customers and if we assigned publically routable IPs on our backbone routers we'd be exposing ourselves to those we wish not to try and crack into. Again, this would be way too confusing for the novice with no IP experience and most likely would turn them away from Amprnet due to their lack of knowledge.

It's important to note, without a firewall, and even with a Virtual Routing and forwarding Instance, these inbound packets would have forwarded to AMPRGW. Unless an operator arranges to use private addresses directly with me, these packets were invalid because my tunl0 interface faces the Global Internet - where use of these IPs are not allowed by RFC 1918. Accordingly, I possess no specific route on my "table 44" that AMPRNet nodes should use to reach these destinations. Other tools to improve security are programs to automate adding and flushing entries on a firewall permitting AMPRNet endpoints to send IPENCAP. Even then, a mis configured client or infected machine within AMPRNet could send a crafted packet to traverse our network, or networks physically or logically adjacent to our nodes.

As you know, a route table alone when you're hosting multiple route tables does not tell a frame how to take it's path. It's the policy that's in place (via ip rules) that tells the frame which route table to use. A firewall doesn't set policy routing, just frame filtering. If you're using RFC-1918 space within say an 802.11 network the edge (as with ISPs) would still have to maintain some sort of a public IP for global routing purposes whether it's for IPEncap or BGP, and RIP would have to announce the path.

This of course is not something you would need to configure, nor would a novice. This would be on the one who's engineering such a network configuration of 802.11 nodes. Someone using RFC-1918 space would have to somehow announce their network within the RIP system so the path to them would be known to you using a globally facing IP as their "gateway" into that subnet. For example, if I had 44.250.250.0/24 via 1.2.3.4, I could route the whole /24 on a network of 802.11 routers using RFC-1918 space and whatever 1.2.3.4 is for a device would have to either be a BGP facing gateway router OR could be an IPEncapsulation system that can chop up my amprnet /24 subnet based on specific RFC-1918 space hosts. You do nothing except allow RIP into your daemon for your policy routing as you do now. As a matter of fact, I am doing that now with multiple 802.11 routers that use 192-net RFC-1918 space and it works just fine. 44.88.0.0/27 routes internally to 192.168.1.1 which then splits that block into two /28 subnets and pushes one of them to 192.168.2.1. You do nothing different on your end and you can see the entire block.

As you mention about firewalling, security is the responsibility of the specific individual that's hosting a subnet of 44/8, which includes anti-spam rules, port filtering, etc. It appears a lot of linux folk like using fail2ban. If you're not encapsulating on your lan and assign an M$ machine a 44-net IP then again it's the individual's responsibility to insure the security of that device. (Ok so that's an oxymoron considering the golden key crack was released)

What I may suggest is if you wish to do a write up on the issues that you're concerned about, make the page and we can link it to the "Requesting A Block" page. There's so many different ways to do security it'd be a good challenge (ie: fail2ban, gShield, hardware devices, etc)

Thank you for all who replay.

I have use tcpdump to check how working iptables

The problem is that "white noise" from bots, hackers etc is incoming from internet and from IP 169.228.66.251. The 169.228.66.251 is main IP router for 44/8 network in internet and unwanted traffic is incoming via IPIP tunnel via 169.228.66.251 for this reason default police in firewall REJECT or DROP, instead of ACCEPT don't help filtering this unwanted traffic.

Pleas use following syntax

tcpdump -i eth0 -n ip proto 4

where eth0 is your internet interface you can see how many frames with source 169.228.66.251 in IPIP which contain frames form boots , scans network , ports your local 44.xx network.

for exmaple:

09:10:09.315252 IP 169.228.66.251 > 192.168.1.2: IP 85.234.252.133.43248 > 44.165.33.1.179: Flags [S], seq 311544230, win 14600, options [mss 1460,sackOK,TS val 7895041 ecr 0,nop,wscale 3], length 0 (ipip-proto-4)

I have try block this traffic by

but not working for me

but one problem with block traffic with source 169.228.66.251 is with information RIP2 09:10:06.730661 IP 169.228.66.251 > 192.168.1.2: IP 44.0.0.1.520 > 224.0.0.9.520: RIPv2, Response, length: 504 (ipip-proto-4)

for this reason I will be block update encap.txt tables via ampr-ripd

Itw ill be nice who write how to use iptables to block nonwanted internet traffic via IPIP with source IP 169.228.66.251 without lose information of RIPv2

We are hamradio and we use amprnet as hobby to run amprnet gateway connect across internet hamradio network and in most case we want to only have links between our local radio network with others hamradio networks and we don't need traffic from internet (boots, hackers , users ) to our local radio networks.

How to run iptables to filter out incoming traffic from intenrte to our local hamradio network via IPIP ????

Please remember that many local amprnet gateways admins are not professional admins and don't have high level knowledge about all problems. Many amprnet gateway have problems with attacks , scans from internet users via traffic incoming from 169.228.66.251 and for thhis reason many radio local networks , servers are not very good protected because many users in local radio network run own WWW server etc without high level protect because they are run/use this server as hobby not processional services.

For my opinion default police on 169.228.66.251 main 44/8 network internet router are set as only pass traffic between amprnet gateways and block internet traffic to amprnet gateways. If anybody like have incoming internet traffic to local 44 radio network you can use for example additional option set ON on portal.ampr..org properties own gateway

73 Waldek SP2ONG

2016-08-20 14:29 GMT+02:00 lleachii--- via 44Net 44net@hamradio.ucsd.edu:

(Please trim inclusions from previous messages) _______________________________________________ To add on to what Rob said.

I also considered you may be simply seeing traffic reaching the inbound side of your tunl0 interface.

This is normal, and is general Internet "white noise" from bots, misconfigured software, viruses, etc. Proper routing and firewalling will ensure that this unwanted traffic is not inputed/forwarded.

• KB3VWG

---

44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net