44net

44net@mailman.ampr.org

3196 discussions

missing packets in to AMPRGW ?
by R P 23 Aug '16

23 Aug '16

Hi can anyone explain why i get every second ping missing packets from AMPRGW ? it happen not only from my PC also from other places ... Regards Ronen-4Z4ZQ http://www.ronen.org Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/> www.ronen.org ronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com C:\Documents and Settings\customer>ping 169.228.66.251 Pinging 169.228.66.251 with 32 bytes of data: Request timed out. Reply from 169.228.66.251: bytes=32 time=336ms TTL=40 Request timed out. Reply from 169.228.66.251: bytes=32 time=286ms TTL=40 Ping statistics for 169.228.66.251: Packets: Sent = 4, Received = 2, Lost = 2 (50% loss), Approximate round trip times in milli-seconds: Minimum = 286ms, Maximum = 336ms, Average = 311ms C:\Documents and Settings\customer>

4 7

Use of 44.128.0.0/16
by DaKnOb 21 Aug '16

21 Aug '16

Hello, as far as I know, 44.128.0.0/16 is reserved for testing and experimentation and should be treated much like an RFC1918 subnet. That means it will not be routable to anyone (although it is advertised on BGP). So I have a few questions about its use: 1. Can an AMPRNet member use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? Note that I am not talking about routing these addresses, just use them in a non-connected place. 2. Can a non-ham use 44.128.0.0/16 in their home instead of, let’s say, 192.168.1.0/24? 3. Can a company use 44.128.0.0/16 for their intranet, instead of, let’s say, 10.0.0.0/8? Note than in all three cases, nobody is connected to 44net gateways and just use the network like any other private address. I am aware that there’s no technical limitation in doing this and there are hardly any benefits from doing this, however I am asking for informational purposes. Thanks!

5 4

Re: [44net] Use of 44.128.0.0/16
by Rob Janssen 21 Aug '16

21 Aug '16

Bogon filter in use on our gateway (all packets with these source addresses are dropped): # ipset list Bogons Name: Bogons Type: hash:net Header: family inet hashsize 1024 maxelem 65536 Size in memory: 17208 References: 6 Members: 10.0.0.0/8 169.254.0.0/16 172.16.0.0/12 198.51.100.0/24 127.0.0.0/8 192.0.2.0/24 213.222.29.194 224.0.0.0/4 100.64.0.0/10 203.0.113.0/24 240.0.0.0/4 0.0.0.0/8 192.168.0.0/16 44.128.0.0/16

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by lleachii＠aol.com 21 Aug '16

21 Aug '16

Waldek, Have you enabled connection tracking for the relevant bridge/VLANs/tunnels, etc. that pass traffic (as this is disabled by default on some systems for non-masqueraded traffic)? In addition, is your default iptables forwarding policy REJECT or DROP, instead of ACCEPT? 73, Lynwood KB3VWG

3 5

Re: [44net] Security/Wiki Question - Requesting a Block
by Rob Janssen 21 Aug '16

21 Aug '16

That "Requesting a Block" page has a lot of personal opinion it and also contains directives that may be valid for some regions but not for others. This already starts with the first line. Here in the Netherlands we don't use the portal for requesting blocks, only for registering blocks that are to be used for IPIP tunnels. So requesting a block does not start with the portal, but with mailing a request for a block to me and allocation of the block in the hostsfile for 44.137.0.0/16 followed by updating the DNS via the robot. Once that is done, it can optionally be registered in the portal. I recommend users not to do this unless they want to setup a gateway, because registered subnets that are not claimed by a gateway are up for grabs by other gateway operators, and given that we have widely varying skills among out users it has repeatedly happened that users (who often not even understand what it means and requires to run an IPIP gateway) create a gateway entry and add someone else's subnet to it by mistake. This then cannot be corrected by either the owner of the subnet or the coordinator of the IP space. It requires a "contact the portal admin" form entry to correct it and that may take a long time to be acted upon. (I still have two open requests of that type) I also don't agree with the "don't waste space" adagium. I allocate whatever is required for the experiment, and now that we are using BGP internally on the radio network, that also includes /30 and /29 networks for point-to-point links (/30 for links with only a router at each end, /29 when it is desired to have AP managment addresses). Unlike on the internet, we have no lack of IPv4 space on AMPRnet! There is no point in using RFC1918 addresses for this, and it causes problems with ICMP messages returned from those routers, e.g. when using traceroute. I also don't agree with "an ISP uses unroutable addresses for routers". Maybe some ISPs do that, but probably most do not. About RFC1918 filtering: YES, everyone should filter RFC1918 addresses at every entry and exit into the network. There are many configuration mistakes in ham networks, and I often see log results on those filters (which I have configured with logging on our gateway). RFC1918 addresses come in via IPIP tunnels from all over the world and also from radio. Of course it requires detailed knowledge of networking, policy routing, and NAT rules to get a mixed net44/rfc1918 LAN correctly connected to AMPRnet (with NAT or blocking for the RFC1918 systems) and let's face it: many users simply don't have that knowledge and are just trying. So, everyone else should filter that traffic so that at least it does not get propagated far. I sometimes send mail to repeat offenders and they often promise me that they will look at it, but it rarely stops completely. Rob

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by Rob Janssen 21 Aug '16

21 Aug '16

> I have use tcpdump to check how working iptables > I have try block this traffic by > but not working for me Again: you can NOT test it this way! tcpdump will show you all packets even when you are dropping them in the filter. I know this is sometimes a nuisance. It is difficult to test if your filters are working. When your filter has the structure of: - some packets dropped - some other packets dropped - more packets dropped - all remaining packets accepted (note that this is normally not a preferred structure of your blocklist) you can work around it by inserting a rule like this just before the last ACCEPT rule (or at the end of the table when the default setting is ACCEPT, again not a preferred situation): iptables -A INPUT -i tunl0 -j NFLOG --nflog-group 44 This will send the packets to a "netfilter logging" interface where you can trace it with: tshark -i nflog:44 (I don't think tcpdump supports dumping nflog interfaces but this may depend on version) The result of this is that all packets that have already been dropped above that rule will not reach the NFLOG target and will not be traced when you trace nflog:44. However, it is normally preferred to work with a "default drop" setup. You accept all packets that you know you want to accept, and drop everything else at the end of the table. This makes it less likely that things pass by that you did not think about, like other protocols than TCP and UDP. It is still possible to have NFLOG logging of everything that is accepted, by first creating a helper table like this: iptables -N NFLOGACCEPT iptables -A NFLOGACCEPT -j NFLOG --nflog-group 44 iptables -A NFLOGACCEPT -j ACCEPT Then you setup your filter table like this: iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -..... -j NFLOGACCEPT iptables -A INPUT -i tunl0 -j DROP Rob

1 0

Re: [44net] Problem with drop non 44/8 trafic via tunnel
by Rob Janssen 20 Aug '16

20 Aug '16

> I have try block non 44/8 traffic via tunnel IPIP with iptables but without > success > I have use ampr-ripd to create port 'tunl0' > I have add to firewall rule: > iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP > but I have still a lot of traffic via tunl0 non 44/8 ip address and it is > look like this not working for me How did you validate that you still have the traffic? Does such traffic still reach an open port on your system or a system behind it? E.g. when you have telnet or ssh running, can you still telnet or ssh from internet? Note that using a trace tool like "tcpdump" or "tshark/wireshark" is NOT a valid way of testing of those filters work! When you do "tshark -i tunl0" with the above filters in place, you will still see the traffic. This is because tshark and tcpdump trace the real traffic on those interfaces BEFORE the filters have been applied. Rob

1 0

Problem with drop non 44/8 trafic via tunnel
by Waldek Waldek 20 Aug '16

20 Aug '16

Hi I have try block non 44/8 traffic via tunnel IPIP with iptables but without success I have use ampr-ripd to create port 'tunl0' I have add to firewall rule: iptables -A INPUT -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP iptables -A FORWARD -i tunl0 -p all ! -s 44.0.0.0/8 -j DROP but I have still a lot of traffic via tunl0 non 44/8 ip address and it is look like this not working for me I have add one more rule like where eth0 is my internet port iptables -A OUTPUT -o eth0 -s 44.0.0.0/8 -j DROP and it is help me to not send to internet 44/8 ip traffic but I would like block incoming non 44/8 IP address via tunnel -- Waldek sp2ong

1 0

Re: [44net] iptables
by lleachii＠aol.com 17 Aug '16

17 Aug '16

It appears the the iptables rule is incorrect. In my previous configuration I had a border device NATing to a downstream device running as my AMPRNet Gateway. When I first set it up, I had THE EXACT SAME ISSUE YOU ARE EXPERIENCING. I could only receive packets after first initiating them. When asking for advice, I continued to receive information that the iptables rules were correct... THEY WERE NOT!!! Why??? As you are receiving this traffic the router interface, IT IS CONSIDERED INPUT since there are no routing rule to forward the packet (this is only done the subsequent DNAT rule added to the iptables firewall). This is an example from my DD-WRT device when I DNATed to a IPIP gateway downstream (so, this is a known working configuration): # iptables -t filter -I INPUT -p 4 -i eth0.1 -j ACCEPT # iptables -t nat -I PREROUTING -p 4 -i eth0.1 -j DNAT --to-destination 192.168.0.11 Further, on the INPUT rule, you could use the -d argument and the IP address if your WAN interface has a static address. Also, after I added this rule to my device, the issue Rob describes doesn't occur (except when I explicitly added a rule to block Pings). 73, - Lynwood KB3VWG

2 1

Re: [44net] iptables
by Rob Janssen 17 Aug '16

17 Aug '16

> It is behind my ISP cable modem, I had to get it setup in bridging mode > after the last time they upgraded it. My router is showing all the > tunnel traffic (via tcpdump) so I'm fairly certain the modem isn't the > issue. Ok. I heard before from other members of this group that they had a similar setup, yet I was never able to ping them unless they first pinged me. > Central to my confusion at the moment is the rule in the nat PREROUTING > isn't counting packets. Remember that iptables NAT processing in Linux is stateful. It only sees "new" traffic for a connection. Once a connection is in the NAT table, the traffic goes "around" those rules much like Established/Related traffic in the filter tables, but without an explicit visible rule for that purpose. So, when you ping outward over a tunnel, you will not see those rules matching yet the traffic is forwarded as reply to your outgoing pings. Only when you ping from somewhere else, those rules are going to be of influence. But of course they only see traffic when it actually arrives on your router. Rob

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net