> Rob,
> I thought the script took care of routing. So I would have to create new routes for 44net to go to the IPIP tunnel?
It should not be required for 44net, but only for internet. I.e. for communication between your 44net hosts
and systems on internet outside 44net. That traffic has to be forced through the IPIP tunnel to UCSD (169.228.66.251)
instead of directly to your ISP, which will drop it.
This can be achieved by creating the 44net routes in a different routing table, I'll wait to see if Marius joins
the discussion to find how this is best achieved when using his script. I am not using IPIP myself on my MikroTik,
I have a VPN to another system and use BGP. There I have configured the BGP to put the routes in a separate
routing table named amprnet and configured some IP Route Rules so that this table is used for amprnet traffic only.
Rob
> I have some dumb questions about setting up the MicroTik. I currently have
> everything set(I got all the RIP records and routes created), however, it
> can't talk to the internet. I'm trying to figure out, would this be a
> firewall issue? Do I need to create a whole new NIC just for the 44net?
When you want to route from net-44 addresses to internet (non-net-44), and
your ISP implements source address filtering (BCP38) you need to setup policy
routing, because you need a separate default route for traffic from your public
internet address (pointing to your ISP) and for traffic from your net-44
systems (pointing to the IPIP tunnel to UCSD).
Rob
Thank you to all that responded to my email, I made my request through the portal.
I would like to provide free tunnel services to any amateur that applies and issue 44net addresses to those who qualify. I also will be experimenting locally with RF.
I am currently connected to AT&T at 10gbits/sec, should be snappy.
Thanks!
John
KD5ZZH
> So my question is this: Is what I want to do feasable as a way to get a
> static address and act as an AMPR gateway?
Yes, this works quite well. I have the same setup here.
I have a colocated Raspberry Pi that is on the IPIP mesh using ampr-ripd in
the standard setup that is described on the WiKi, and it serves my subnet and
a couple of /32 addresses.
My subnet is tunneled to my home using IPsec in AH/Tunnel mode. Using AH
instead of ESP (as is usually used) reduces CPU usage, and encryption is not
required for this purpose anyway. At home I have a MikroTik router.
I do have a fixed IP at home so IPsec is easy, when you don't have that it
may be easier to use a VPN that does not care about addresses, e.g. OpenVPN.
I also run a couple of applications locally on the Pi, hence the /32 addresses.
Today, thanks to Marius' work, it is also possible to use a MikroTik router
instead of the Raspberry Pi. It may be easier to configure and is available
in rackmount formfactor.
Rob
Greetings. I'm somewhat new to the list and would like to join the network.
I am not able to get a static address from my ISP, well I could, but I'd
have to get a business account and my speeds would be a lot slower than
they are now. I'm considering getting a VPS or a colocated raspberry pi to
act as a vpn server and my point of presence to connect to my network via a
tunnel. A rough ASCII diagram follows:
(^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
( IPIP/Tun0/VPN Svr <<--- )
( Ieth0 RasPi in DATA CENTER)
(vvIvvvvvvvvvvvvvvvvvvvvvvvvv)
I
(^^I^^^^^^^^^^) (^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^)
( Internet )====(>LinuxRouter/VPN/Tun0/eth2-->>44.98.63.0/29)
(vvIvvvvvvvvvv) (vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv)
I
(^^I^^^^^^^^)
(IPIP @ SDSU)
( 44/8 )
(vvvvvvvvvvv)
My intent is to initilly have connectivity for a small LAN and then build
it out over AX25 for my local area. I've run linux as my router/firewall
(iptables and ipset) since 2012, but have not done much with "ip route" or
"route", tunneling or anything with bridging but I did play a little with
GRE and OpenSwan a couple of years ago. My thinking is building tun0/eth0
bridge and feeding that through the VPN to the distant RasPi which would
vbidge the other end of the connection to the IPIP tunnel.
So my question is this: Is what I want to do feasable as a way to get a
static address and act as an AMPR gateway? Any suggestions, hints or
approaches to prod me in the right direction to get me going would be
appreciated.
--
tom
73 de N2XU/Tom Cardinal/MSgt USAF (Ret)/BSCS/Security+/IPv6 Certified
All,
KD5ZZH here. I currently run an ISP (AS 62744) and I would like to provide an exit bridge to the public internet and link the Tom Green<x-apple-data-detectors://0> County, TX area as well.
How does one go about getting a /24 out of the block?
John Ricketts, PhD
Quintex Alliance Consulting
(325) 263-3488<tel:(325)%20263-3488>
Hello all,
It seems that the ampr-ripd daemon will be included into Debian by the
DebianHams group.
To be able to fit into an easy setup for all fellow hams, after
discussions with Brian Kantor and Ana C. Custura taking care of
packackaging it, we reached the following conclusions:
- The RIP password was never actually meant as a security feature, more
a validation mechanism
- Everyone having access to the RIP data can actually extract the
password by sniffing the stream
- Since access to the network implies a gateway registration, and the
RIP sources are well defined and restricted, the password could be ignored.
Now, as a result of these discussions, I made some changes to the
ampr-ripd daemon:
- the RIP password is now included into the source file. The RIP data
will continue to be validated against this password.
- the password option can be omitted, but is still there for
compatibility reasons and if it would be necessary to change the
password at a later time
- password discovery via debug mode still works
- a man page for ampr-ripd was added (Tnx. Ana)
You can get the updated ampr-ripd from:
Internet: http://www.yo2loj.ro/hamprojects/ampr-ripd-1.14.tgz
44Net: http://yo2tm.ampr.org/hamprojects/ampr-ripd-1.14.tgz
or from GitHub:
git clone https://github.com/yo2loj/ampr-ripd.git
Have fun,
Marius, YO2LOJ
Gentlemen, if we cannot discuss a matter calmly and rationally,
we should not discuss it at all. What we are after here
is light, not heat.
Incendiary comments are not welcome on this mailing list.
Control yourselves.
- Brian
It would still be an option to merge the portal and hamnetdb...
Hamnetdb is much more capable when managing subnets, and it is open.
There is an issue with scalability (it always shows you all the data it has when first opening a page,
before you have applied a search filter, which really loads older computers), so there may be
surprises when all of the world's data is loaded into it.
The "gateways" functionality is not yet there, so it would have to be implemented.
But issues like the one that started this discussion are easier to resolve in hamnetdb because
every object has a list of maintainers, which the owner or a sufficiently privileged person can
modify. So you can easily hand over control over your subnet (e.g. to include it in a gateway)
to someone else without sysop involvement.
Rob
> That's fine for YOUR users because you keep a separate database of what
> is allocated and what is not in your country's subnet, but I and many of
> the other coordinators use the subnet allocations in the portal as the
> authority for what is allocated and what is available. It is essential
> that all subnets be registered in the portal in order for me to do my job.
For me, the portal is not usable as the only registry of information, because it
does not do DNS and DNS is essential for the functioning of the network.
(not only because you want to name your system, but also because being in DNS
is used as a filter to allow traffic through the gateway)
So I need to keep two different registries anyway, and it does not matter how
much of the information is in the portal and how much is in my own database.
Furthermore, for allocating subnets and addresses I need an easily browsable
view on the existing allocations including comments like regional names, to be
able to decide where to put the new entry.
To me, a simple "hosts" file edited in vi gives more overview than most point
and click interfaces, including even that of the hamnetdb (which is way better
than the portal in this regard).
This solution also reduces the effort when making bulk changes like moving an
entire subnet, doing cleanups like I did some time ago, or even transfer of the
existing allocations into the portal. Sure they would be possible with a tool
like this but it would either need a lot more features (and thus coding) or it
would have to offer direct access to the database for queries.
Rob