> Of course a special version of ampr-ripd could be made that ignores those routes when some flag is given.
Or rather: add a flag that specifies an alternate route table number where those routes will be stored
instead of the main table or the table specified with -t
A special value (0, -1) could be used to entirely ignore those routes.
Rob
Hello,
Beginning on March 15th, the pseudo-RIP transmissions from amprgw
will include the various subnet prefixes which are being advertised
by BGP. They will show a next-hop address of 169.228.34.84, which
is amprgw.
Marius assures me that this will cause no harm, and will enable
tunnel-only AMPRNet hosts to reach those destinations via the tunnel.
He says that many tunnel-connected hosts have a semi-default route
to amprgw that has to be manually installed when the system is set
up; this would now be automatic when employing the various ampr-rip
programs.
Quoting Marius:
So, wouldn't it make sense to publish BGP routed networks that
do not have 'tunnel ' set in the portal as RIP routes using
amprgw as gateway?
This would solve some issues: - Users could actually see all
reachable destinations in their route list
- Users could easily identify BGP networks by checking 169.228.34.84
as their gateway
- they could drop the setting of that 'default' route in the
ampr routing table, allowing a (implicit) throw to the main
table. This will make it easier to reach local or directly
connected ampr networks (which now need routes placed in the
ampr table). Also, unknown destinations would be NATed to the
system's gateway, without putting any additional traffic to
amprgw.
- it would also allow to have all routes in a single routing
table while being able to reach tunneled and BGPd networks using
their AMPR address without policy routing.
Existing set-ups would not affected by such a change in any way.
Marius, YO2LOJ
Please be sure to let me know if there are any problems with this
change; it can be reverted in a matter of moments if an unexpected
difficulty does arise.
- Brian
I connected via VPN.
IPv4 Address. . . . . . . . . . . : 44.139.11.22
Subnet Mask . . . . . . . . . . . : 255.255.255.252
My DHCP server is 44.139.11.21. I am not able to ping that server.
I can't ping ampr.org.
Actually, I tried pinging several IP addresses and nothing is returned.
I'm trying to figure out if connecting via VPN is of any useful value?
Mike N9MS
Marius,
Ok that is an interesting solution!
It solves the "route lookup" issue, but in the case of using BGP there isalso the issue that
BGP only distributes the subnet route when there is an actual matching route in the table that it is
managing. Of course this can by circumvented by unchecking the "synchronize" option.
And on our local AMPRnet we distribute the default route via the same BGPinstance as the
remainder of the routes. So that would have to be changed.
I'm inclined more towards a script that reads the interface routes from the main table and copies
them into the amprnet table...
Rob
> The forwarded packets
> that were supposed to go to my 'inner' server were also routed back to
> the AMPR GW, which of course did not know anything about my local
> addresses (192.168...).
> However, after adding this line:
> ip route add 192.168.19.0/24 dev enp0s6 table 44
> everything felt in place and I'm now a happy man.
Unfortunately this is a detail that is soooooo easy to oversee that it frequently happens.
But of course it is always educational to encounter this and fix it yourself!
E.g. I recently helped someone with a MikroTik router to setup this kind of policy routing
and on that router the direct routes to attached interfaces also only appear in the main
routing table and not in those additional ones. There really should be an option to do that
automatically, but until then indeed you have to add them manually.
The kernel would lookup the route in the main table when it cannot find a route in the
additional table, but of course that only works when there is no default route there.
And autorouting protocols like BGP won't distribute the route when it is in the wrong table.
Rob
There were 2 RSA keys in my n9ms keys file. The 2nd one was the correct
one. Then I got an error message telling me that OpenVPN couldn't connect
due to a weak algorithm. Adding the following line to the .opvn file fixed
it.
Mike
tls-cipher "DEFAULT:@SECLEVEL=0"
I'm already using OpenVPN and it works great.
Now, I'm trying to use OpenVPN to establish a tunnel to AMPR.ORG.
I followed the instructions at: http://wiki.ampr.org/wiki/AMPRNet_VPN
I get the following message in my OpenVpn Log:
Tue Mar 05 12:19:13 2019 WARNING: --ns-cert-type is DEPRECATED. Use
--remote-cert-tls instead.
Tue Mar 05 12:19:13 2019 SIGUSR1[soft,private-key-password-failure]
received, process restarting
Tue Mar 05 12:19:13 2019 MANAGEMENT:
>STATE:1551813553,RECONNECTING,private-key-password-failure,,,,,
Tue Mar 05 12:19:13 2019 Restart pause, 5 second(s)
--- and it repeats ---
Hi
I have acquired myself a problem. Recently I decided to move all web
services away from the gateway to an ‘inner’ server. This is easily done
by using port forwarding in the firewall on the gateway. Thus I forward
all web services by using this line:
iptables -t nat -A PREROUTING -p tcp -m multiport --dport $Services -d
$EXT_IP -j DNAT --to $webserver
where $Services is defined as
Services="smtp,domain,www,https,submission,imaps",
$EXT_IP is my external IP address and $webserver is the IP address of
the ‘inner’ server.
I do the same for the ampr interface:
$iptables -t nat -A PREROUTING -p tcp -m multiport --dport $Services -i
ampr0 -j DNAT --to $webserver
In this case it is only the www and https services that are relevant
since I do not do mail on the 44-address.
All of this works of course as it should for ordinary IP addresses
(non-44) and it also works fine when comming from a 44-address.
Furthermore it works fine when I ping my 44-address from any IP address
(which isn't surprising as ICMP is not forwarded). But it fails
miserablywhen accessing my 44-address (44.145.40.3) from an ordinary IP
address. The incomming request comes nicely in on the ampr interface,
but the reply goes out the WAN interface to the Internet at largeand is
thus not recognized as a reply on the originating host.
I have spent quite a bit of time trying to findout why this is so. I’m
convinced it is something in my setup that is the cause of this
behavior, but I’m at a loss as what it may be, so I hope some of you
eagle-eyed people out there can spot the error.
Here are somedetails of my setup.
Routing rules:
$ip rule list
0: from all lookup local
44: from all to 44.0.0.0 /8 lookup ampr
45: from 44.145.40.3 lookup ampr
32766: from all lookup main
32767: from all lookup default
Main routing table:
$ip route list
default via 86.48.99.33 dev enp0s7 metric 3
127.0.0.0/8 via 127.0.0.1 dev lo
192.168.19.0/24 dev enp0s6 proto kernel scope link src 192.168.19.6
‘ampr’ routing table (table 44) (excerpts):
$ip route list table ampr | head -n4
default via 169.228.34.84 dev ampr0 onlink
44.2.0.1 via 191.183.136.1 dev ampr0 proto 44 onlink window 840
44.2.2.0/24 via 216.218.207.198 dev ampr0 proto 44 onlink window 840
44.2.7.0/30 via 98.208.73.100 dev ampr0 proto 44 onlink window 840
My gateway is a Soekris Net5501 running Gentoo Linux updated to the
latest versions last Monday.
I do hope I have expressed myself clearly enough and provided details
enough so that one of you can point at something and say: ‘there is your
error’. If some information is missing or lacking please ask for it and
I’ll provide as much as I can.
Best 73 de Bent/OZ6BL
Hi, I'm new to this forum. Several years ago I used Packet Radio and had an
IP address (it is still active: n9ms.ampr.org [44.72.58.62]).
Now, I'm getting active on the AREDN Mesh Network. I'm wondering if my
n9ms.ampr.org would be useful on our mesh network -- maybe it's strictly a
Packet Radio thing? I'm just curious.
I looked at the Gateway information, but I didn't see anything in there for
my IP address -- but I could be wrong.
Thanks for your help.
Mike N9MS
