> The power can be provided by a picopsu 150 watt is usely more then enough
The CCR1009 (a router with 9-core 1200 MHz TILE CPU, 1 10Gbps and 8 1Gbps ports)
consumes 20 watt in actual use. It comes with dual (redundant) powersupplies,
dual (redundant) fans (or passively cooled) and is ready to use for $495
The RB1100 is even less, $299 without or $349 with the 60GB disk option.
Rob
> I would go with a small itx pc with dual gygabit nic and a 4 port pcie gygabit nic. that give you 6 nic in a box.
> Run this under Openwrt, or opensense or pfsense. You could even run miKrotiK OS
> you can have a small ssd in there and 4 gig of ram to be sure all is ok and this setup would be able to do all of your need and even more.
Of course it also uses more power, and takes more effort to construct and install.
It can sometimes be useful to have more flexibility, but for general router usage it usually is overkill.
Those MikroTik boxes work after unpacking and some basic config tasks. However you can still spend hours and hours
to make them do a lot more :-)
Rob
I agree with what Marius wrote. Those models will perform very well in a network like
that. We use a CCR1009 in our gateway for the 44.137.0.0/16 network (BGP routed on internet)
and use it to provide VPN services to users and nodes inside the country, and to feed the radio
network as well. The RB1100AHx4 should be equally capable of that. I would avoid the RB3011,
should there be a tight budget or should there be a need for smaller devices at other places
in the network it is better to use models like RB750Gr3 or the proven RB2011.
As with any router and in fact with any device connected to internet, you will have to make
sure it runs uptodate software (software can be upgraded for free as long as the device gets
software updates, which will be quite some time for these models) and also you have to
configure it in a reasonably secure way, e.g. make sure the management interfaces
(telnet, ssh, webfig, winbox) are only accessible for your own people and not for the internet
at large. This can be done by restricting them to certain interfaces, subnets, individual addresses
on internet, and/or by using a VPN for management access.
Keeping the management ports (22,23,80,8291) open on internet has proven to be a recipe for disaster.
Rob
Hello,
There is a problematic entry in the portal which needs our attention:
44.151.31.6 / 32 via 44.151.31.6, according to the portal allocated to
F1SXO, France, Occitanie, Haute Garonne
The problem is that the RIP entry 44.151.31.6 via 44.151.31.6 is wrong,
ilogical, and creates a routing loop.
On Mikrotik routers, this will sow as a flapping of the ampr-44.151.31.6
interface.
The solution for the moment is to filter that entry in the RIP filters
and delete the 2 routes to it and its associated interface by hand.
I had no time to check the behavior on ampr-ripd and amprd systems but
is basically lead to the flapping of the route.
After correcting this issue in the portal, on these systems, a remove of
the static route 44.151.31.6 via default gw should be necessary (ampr-gw
and amprd do not remove those static routes - known problem).
The final solution is to correct the entry in the portal.
Marius, YO2LOJ
Now that my BGP announced 44.x range is up and running, I'd like to be
able to make it transparently accessible for tunneled networks. I just
need to double check a few things.
First, I know I'd need to run ampr-ripd on the box. I also have non-44
net addresses to use as the ipip encap endpoint. What else do I need to
do? Do I need to advertise the subnet as "tunneled" in addition to
direct in the portal? Anything else?
Reason for this is I'm likely to be running services other than Echolink
proxies, which may require peer-peer connectivity. Currently, 44.x
tunneled addresses connecting to the system would go via their local
router, which most likely involves NAT.
And on a similar note, is there a way to exclude other directly
connected subnets capable of IPIP tunneling from using a tunnel? (since
that's obviously not required!)
--
73 de Tony VK3JED/VK3IRL
http://vkradio.com
> How does Echolink distinguish "incorrect password" from other
> conditions? Or does it assume that if a connection is dropped at a
> certain stage, then it's an incorrect password?
Well my description was from memory and not entirely correct.
There are only two error codes that a proxy server can return to the client,
one for "bad password" and the other for "access denied"
(i.e. the presented callsign fails the check to the CallsignAllowed or CallsignDenied
patterns in the config, usually using wildcard checks like "deny -R" to deny repeaters)
However, there is no error code for "proxy busy", a busy proxy simply disconnects new users
before they even authenticate.
There is also no way to return an error message text, the error is returned as a code
and the client issues an appropriate message to the user.
So you cannot communicate a more detailed message like "this proxy is reserved for ...".
However, you can use a private proxy (different password) to achieve that.
> But yes, good idea, I can block incoming connections on TCP 8100 (proxy
> port) on the IPs that conferences are using. Thanks for that suggestion.
Indeed, when you setup your firewall to just refuse connects from other systems they will
believe this proxy is busy. However, when the proxy used by the conference is private
and (nearly) always busy, there is not much you need to do as it works fine by default.
The worst that could happen is that someone DoS'es you by repeatedly trying to connect
to the proxy at a time the conference server isn't connected and then proceed through
the authentication as slow as it can, and once it gets disconnected immediately re-connect
before the conference had a chance to do that. I have not yet encountered such behaviour.
Rob
> Now that my BGP announced 44.x range is up and running, I'd like to be
> able to make it transparently accessible for tunneled networks. I just
> need to double check a few things.
> First, I know I'd need to run ampr-ripd on the box. I also have non-44
> net addresses to use as the ipip encap endpoint. What else do I need to
> do? Do I need to advertise the subnet as "tunneled" in addition to
> direct in the portal? Anything else?
That is all you need to do. There is no need to setup policy routing ("ip rule")
in this case, and also you should not add any static routes such as a default
route for AMPRnet traffic. Only use the routes provided by ampr-ripd and load
them into the main table. Indeed you need to check "tunneled" in the portal.
It is a desirable step for any BGP advertised subnet, not only for the echolink
proxies, to do this. It will allow communication with those that are "only"
on the tunnel mesh (i.e. they do not route towards internet, or do NAT when
routing to internet), and it is more efficient than doing that via another gw
like ampr-gw. And it is quite a simple setup.
Of course you should also consider the effect on the firewall settings.
Rob
> One thing I would like to be able to do with the proxy server is have a
> whitelist and blacklist of local IPs, so no one can accidentally DoS a
> conference running on the same server, or find themselves with a non
> functional proxy (and a lot of head scratching!), because the UDP ports
> are being used by a conference. If they connect on a blacklisted IP,
> the proxy would simply issue an error saying connection is not permitted
> (since the TCP side can safely be opened, this should work).
Proxy servers do not issue error messages. They only thing they can do when
they don't want your connection is to simply close it immediately, or refuse it
entirely. You can solve that in the firewall.
However, when you want to reserve a proxy for a conference or other usage, you
can simply set a different password than PUBLIC for it. That will make it a
private proxy which can only be used by a user or service who knows the password.
(and it will not appear in the proxy list)
Rob
> >/I think your best and safest bet would be to find a conference server /> >/that can use a proxy. /> I don't understand what you mean, this looks self evident to me.
What I mean is: is the conference server that you want to use configurable
so that it does not open a set of UDP sockets, but instead connects to a proxy
server you specify (address, port and password) ?
If so, just configure it to connect to one of the proxies you run in elproxy
on the same machine and there will be no issue and no uncertainties.
Of course, when it works directly on a set of UDP ports without disturbing the
proxies and relays running on the wildcard socket on the same machine, that
is fine as well.
Rob
All,
I hope some of you may be more familiar whit getting software added to Open Source projects than I am. Is this the primary location for the ampr-ripd makefile, or does anyone else maintain the makefile elsewhere?
https://github.com/rufty/ampr-openwrt
Also, in my ampr-ripd, I require the following line to compile for OpenWRT:
#define IPPORT_ROUTESERVER 520
This is not reflected by a patchfile. Has anyone had success compiling ampr-ripd for OpenWRT without adding the line above?
73,
- Lynwood
KB3VWG