Because of concern that the rip sender might be sending
the pseudo-RIP packets to gateways faster than they can
receive them, I have changed the sending order.
There are currently 26 packets per gateway per transmission.
Instead of sending all packets to a gateway, then sending
them to the next gateway, and so on, now each packet is
sent to each individual gateway before the next packet is
generated and sent.
This has the effect of inserting a few milliseconds delay
between consecutive packets being sent to any one gateway,
which should give the receiving process more time to handle
the transmission.
The same total data is sent, so nobody should miss out on
any routes.
Thanks to Rob, PE1CHL for suggesting this technique.
- Brian
> 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
It must be something in your 2.238.198.249 system or the path to it, because
I can ping 44.134.160.1 without problem from other internet hosts.
Rob
I don't remember seeing PHPIPAM mentioned here before. (And I searched...)
https://phpipam.net/
Perhaps it would be useful - if not for the overall process for local
or regional LANS.
73
Bill, WA7NWP
I think I have asked it before but i see on the log a lot of incoming UDP port 5060 to all the hosts (even that are not active currently but defined in the AMPR dns and therefore have routing to my gateway ) from all over the world
What is it ? who have interest to look for SIP on my system ?
Is there a way to cut and paste part of the log of Mikrotik router ? i can not do it when i enter it from the web interface so could not copy the relevant log part
Thanks Forward
Ronen - 4Z4ZQ
http://www.ronen.org
Ronen Pinchooks (4Z4ZQ) WebSite<http://www.ronen.org/>
www.ronen.orgronen.org (Ronen Pinchooks (4Z4ZQ) WebSite) is hosted by domainavenue.com
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
> 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
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
> 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
> - 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
