44net April 2017

44net@mailman.ampr.org

41 participants
78 discussions

misconfigured encap routers?
by Brian Kantor 22 Apr '17

22 Apr '17

I've been analyzing some of the encap traffic and finding unexpected things. Several sources of ipencap'd packets being received by amprgw have non-44 inner source addresses. Would you all agree that a protocol-4 (ipencap) packet reaching the UCSD gateway should always have an inner (encap'd) source address on the 44-net? And that those that don't should be considered bogus and be discarded? - Brian

15 34

Re: [44net] Enabling traffic from inet to 44-net and vice versa
by Rob Janssen 21 Apr '17

21 Apr '17

> anybody knows how to filter this traffic with IPTables ? > It would be very helpful. Where is that traffic originated? Is that the address of your own system? If so, it can help to set a preferred source address on your routes towards amprgw. (add src 44.134.x.y to the route command) Rob

1 0

Enabling traffic from inet to 44-net and vice versa
by Marco Di Martino 21 Apr '17

21 Apr '17

Hi all, I'm checking my configuration at the gateway ampr-italy-gw.ampr.org due to an issue on routing. This gateway is the main one in the Country and manages several subnets interconnected via VPN (OpenVPN). The ampr-italy-gw.ampr.org is the point of contact with the AmprNet and it's handling the IPIP tunnel. I would like to permit traffic from inet to 44-net and vice versa and, of course, only for specific 44-net hosts that have the corresponding entry in the Ampr.org DNS. Well, it doesn't work :) Here is how the ampr-italy-gw.ampr.org router manages the traffic between inet and 44-net: ip rule add from 44.0.0.0/8 table 44 prio 200 GW_ADDR="169.228.66.251" # /sbin/ip route add 128.0.0.0/1 via $GW_ADDR dev tunl0 onlink table 44 #128-255 /sbin/ip route add 64.0.0.0/2 via $GW_ADDR dev tunl0 onlink table 44 #64-127 /sbin/ip route add 0.0.0.0/3 via $GW_ADDR dev tunl0 onlink table 44 #0-31 /sbin/ip route add 48.0.0.0/4 via $GW_ADDR dev tunl0 onlink table 44 #48-63 /sbin/ip route add 32.0.0.0/5 via $GW_ADDR dev tunl0 onlink table 44 #32-39 /sbin/ip route add 40.0.0.0/6 via $GW_ADDR dev tunl0 onlink table 44 #40-43 /sbin/ip route add 46.0.0.0/7 via $GW_ADDR dev tunl0 onlink table 44 #46-47 /sbin/ip route add 45.0.0.0/8 via $GW_ADDR dev tunl0 onlink table 44 #45 -- [root@ks28006 ~]# ip rule list 0: from all lookup 255 200: from 44.0.0.0/8 lookup 44 32766: from all lookup main 32767: from all lookup default The table 44 has a higher priority than the main table where the routes for each gateway are contained (basically what comes from the encap.txt). It should mean that when a 44-net hosts wants to reach an inet host, it happens through the amprnet router at UCSD.edu and not directly via the eth0 interface. Now, if I send ICMP packets from 2.238.198.249 to 44.134.160.1, the following is what I see with tcpdump at the ampr-italy-gw.ampr.org: eth0 (tcpdump -n -i eth0 proto 4) 21:36:36.915644 IP 169.228.66.251 > 91.121.90.186: IP 2.238.198.249 > 44.134.160.1: ICMP echo request, id 1, seq 51, length 40 (ipip-proto-4) 21:36:36.937888 IP 91.121.90.186 > 169.228.66.251: IP 44.134.160.1 > 2.238.198.249: ICMP echo reply, id 1, seq 51, length 40 (ipip-proto-4) tunl0 (tcpdump -i tunl0 host 44.134.160.1) 21:36:36.915664 IP 2-238-198-249.ip245.fastwebnet.it > iw2ohx.ampr.org: ICMP echo request, id 1, seq 51, length 40 21:36:36.937872 IP iw2ohx.ampr.org > 2-238-198-249.ip245.fastwebnet.it: ICMP echo reply, id 1, seq 51, length 40 My understanding is that it's working correctly, because the icmp reply is sent back to 2.238.198.249 inside the tunnel and towards the amprnet router (169.228.66.251). Unfortunately there's something wrong in the middle because no packets are actually reaching 2.238.198.249 C:\Users\marco>ping iw2ohx.ampr.org Pinging iw2ohx.ampr.org [44.134.160.1] with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 44.134.160.1: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss), Any ideas ? Thanks for the help Marco iw2ohx

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 21 Apr '17

21 Apr '17

> For me, most all of the bad stuff is coming in via the spoofed ampr gateway address of 169.228.66.251 When you see internet traffic as bad stuff, you will receive a lot of it from that address, but most of it will not be spoofed. It is traffic from internet to your AMPRnet address(es) that is being relayed, the intended purpose of amprgw. Maybe there should be a separate filter for incoming traffic via the gateway. We have that on our gateway: a local AMPRnet user can indicate if they want to receive incoming connects from internet and they are placed in a bitmap ipset similar to the bitmap created from the DNS hosts. By default they are not in that map, and only replies to outgoing traffic are allowed. Of course this is only possible because we run connection tracking on our gateway, which is probably not done on amprgw. It keeps out a lot of junk. A simple version without connection tracking could block incoming TCP SYN and maybe some UDP traffic to ports like 53 and 161 and others. That would still mean there has to be some registration capability to turn this on/off per address. DNS is already used to control the strict allow/deny per address, so it cannot be used for this. Rob

1 0

Re: [44net] OpenWRT 15.05 upgrade to LEDE 17.01.1
by Rob Janssen 21 Apr '17

21 Apr '17

> - HTTP: 44.60.44.10 Now I can access your service for the first time. Rob

1 0

Re: [44net] misconfigured encap routers?
by Rob Janssen 21 Apr '17

21 Apr '17

> - make an IP tables rule AFTER (-A [APPEND]) your ALLOW IPENCAP from > AMPRGWS - to DROP IPENCAP > - let us know if you get any firewall hits by checking your running > ipencap list I have done that for a while and I do not see a lot of traffic, but there is some. Part of it is from gateways with dynamic address. When their address changes it takes a while for the update to bubble through DNS, the portal and AMPR-RIP, and during that time the traffic from their new address is dropped. But that does not matter, as return traffic would not arrive there either. A gateway with a daily changing external address is really not workable. Lately there has been a lot more bad GRE traffic. We run GRE tunnels as well, with a similar protection, and the default drop rule has logged quite some traffic the past months. Research indicates that it is related to a hacked video recording system, although it is unclear to me what the purpose or cause of the GRE traffic is. When browsing to the source address of these packets, one gets a logon screen of some Chinese video recording (for surveillance) system. Rob

1 0

Re: [44net] OpenWRT 15.05 upgrade to LEDE 17.01.1
by Rob Janssen 21 Apr '17

21 Apr '17

> Tom and Ruben, > traceroute to 44.165.2.4 (44.165.2.4), 30 hops max, 60 byte packets > 1 kb3vwg-001.ampr.org (44.60.44.1) 1.385 ms 1.392 ms 1.593 ms > 2 mail.sp2l.ampr.org (44.165.2.2) 154.783 ms 171.077 ms 171.653 ms > 3 home.sp2l.ampr.org (44.165.2.4) 171.674 ms 171.668 ms 171.650 ms I cannot ping, connect or traceroute you either. When it works from your side and not from ours, are you sure you have a *working* incoming IPIP protocol forward or DMZ host? It is all too common for stations behind ISP NAT modem/routers to have IPIP tunnels that work only outbound (and replies), not for unsolicited inbound traffic, because they only admit IPIP traffic as replies to their own outging traffic, even when they have set a DMZ host in their router. (which often only works for protocols like ICMP, TCP and UDP) Rob

4 15

Re: [44net] encapsulated ipencap packets
by Rob Janssen 20 Apr '17

20 Apr '17

> Regarding the other thread about which firewall rules to use, the > gateway is a little more complicated but for my home router I > (normally, not last night in case you saw differently) have the > equivalent to: > iptables -t filter -A FORWARD -i tunl0 ! -d 44.131.14.128/26 -j REJECT > iptables -t filter -A FORWARD -o tunl0 ! -s 44.131.14.128/26 -j REJECT > I think this pretty much covers the requirements for a basic end network? For the outgoing side, yes. It would be very helpful when everyone had a filter like that. For the incoming side it is a bit too simple. It covers the case where hackers send packets that you would then forward, but that can also be covered with a iptables -A FORWARD -i tunl0 -o tunl0 -j DROP However, it would still be advisable to: - only accept tunnel traffic from registered gateways (I have shown on the list how to do that a couple of times) - attempt to screen the source address of the tunneled traffic a little (e.g. accept non-44 traffic only from the gateway, as shown earlier today, and even better: to reverse path checking for tunnel traffic, i.e. only accept traffic from each tunnel whose source address matches the subnets registered for that tunnel) > If the main gateway receives an invalid encapsulated packet from a > known gateway or a 44net address, would it be helpful to return an > error instead of dropping it? An ICMP Administratively Denied packet > is more likely to generate an obvious error message than packets going > missing. The gateway would probably need to rate-limit the number of > errors it will send out to prevent abuse, though. This does not bring much, it would only help when someone is actually watching the traffic, and it appears not many people do. When a decapsulating gateway sends an ICMP unreachable packet to the encapsulating gateway, that gateway will not normally attempt to translate it into an ICMP packet related to the inner packet and send that back to the originating system. So the user behind the keyboard will never know. Rob

1 0

encapsulated ipencap packets
by Brian Kantor 20 Apr '17

20 Apr '17

In our tunnels, all traffic from a gateway should be encapsulated and should NOT contain an encapsulated ipencap packet. The ipip router at UCSD logs and discards these; I'm seeing such packets from gateways 77.138.34.39 85.234.252.133 86.161.255.194 185.58.225.84 which suggests that they have a routing misconfiguration. The operators of those gateways should examine their routing and encapsulation rules to see why this is happening. - Brian

2 1

DNS for Belgium (44.144.0.0/16)
by Ruben ON3RVH 20 Apr '17

20 Apr '17

Hey Guys, Does anyone have any contact info for ON4SAX? He should be the maintainer for the Belgium subnets. But I'm not able to mail him through the contact info on qrz.com (on4sax(a)on4sax.be<mailto:on4sax@on4sax.be>) to make DNS changes for my hosts. The domain seems parked and has no MX record as far as I can see. I also saw that the range for Belgium is routed through Wireless Belgium and as such not through ucsd so I am also wondering how I can get incoming traffic from the world (non 44net) to my 44net hosts and outbound from my 44net hosts towards the world. Thanks in advance. 73, Ruben - ON3RVH

2 3

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

44net April 2017