Hi all,
It seems that there is some confusion and I'll try to respond as a small
tutorial so others may benefit from it.
1. Interface IPs and netmasks
An IP defines the local address of an interface, that means the address
to which a packet must be sent to reach that interface.
The netmask on the other hand describes which other addresses can be
reached DIRECTLY from that interface (in network terms, which
destination sit on the same network segment - the subnet in case of an
IP network).
Let's take an example...
On a local network we have an allocation of 44.128.1.0/24
That means that one of those IPs need to be alocated to the device
(let's assume 44.128.1.1).
Now the prefix length/netmask is 24. That means that the first 24 bits
of that address represent the network, while the rest up to 32 could be
usable as individual addresses.
This means that valid addresses on this network are 44.128.1.0 to
44.128.1.255. There are 2 exceptions of usability here. The first
address, 44.128.1.0, which represents the network, and 44.128.1.255,
which is the broadcast address of this network.
So we can use as individual IPs 44.128.1.1 to 44.128.1.254. If we assign
now 44.128.1.1 with a netmask of /24 (or 255.255.255.0 - it is just the
same these numbers have the bits representing the network set to 1, the
rest to 0), this means that all other addresses of this network can be
directly reached by sending them out via that interface.
So we have now our local network, as assigned in the portal.
Let's see how this tunnel interface is exactly described.
It has a local and a remote address, defining its endpoints as a tunnel,
and creates a virtual interface, which will have a network assigned to
it, just like a regular interface.
Lets' say our public IP of our router, provided by our ISP is 1.2.3.4
and we want to reach ampr_gw, which has a public address of 169.228.34.84.
So we need to set our local ip to 1.2.3.4 and the remote ip to
169.228.34.84. This will encapsulate all the virtual interface traffic
as IPIP and send it to 169.228.34.84, and all encapsulated traffic from
169.228.34.84 will appear on our virtual tunnel interface.
Now, the exact same logic of IP and netmask applies to the virtual
tunnel interface.
We could see this in 2 different ways: We could see the ampr-gw
interface as the whole ampr address space, and that means that all 44
addresses could be reached that way, and we could use a netmask of /8
(or 255.0.0.0) or we could consider this interface not able to reach
anything, and we could use a prefix of /32
The difference of these 2 approache is the automatically generated
route, which in the first case would send all 44.x.y.z traffic to the
tunnel, assuming that all destinations are reachable (which is not the
case), or we assume the latter case, that nothing is reachable directly,
and we need a /32 prefix, and we will rely on routing for data forwarding.
So, to cope with our network configuration, we need a /32 netmask for
that specific tunnel interface: only 44.128.1.1 is directly reachable.
Now, let's com back to the routes for the tunnel interface. In the
example, I used 169.228.34.84 as the remote tunnel endpoint. But if we
use 0.0.0.0 as the remote address, the tunnel interface will work point
to multipoint (P2MP) as described below.
A route has 4 components (not necessary all visible to the user):
A network address, a netmask, a gateway and a interface.
The network address and netmask specifies what is routed, the gateway
specifies where it has to be sent to, and the interface via which
network interface to do it.
In case of regular interfaces, this is quite simple.
e.g. route 192.168.2.0/24 via 192.168.1.1 dev eth0 will send all trafic
with destination 192.168.2.0 to 192.168.2.255 to the router having
address 192.168.1.1 and is reachable on the interface eth0
This behavior is different on a linux IPIP tunnel interface. In the case
of the tunnel, the gateway address of the P2MP tunnel describes the
remote endpoint of the tunnel connection for that specific subnet,
allowing us to use a single interface for all 44net tunnels.
So, having our local IP 1.2.3.4 and remote IP 0.0.0.0, we can have
routes like this:
44.128.2.0/24 via 2.3.4.5 dev tun44
44.128.3.0/24 via 3.4.5.6 dev tun44
44.128.0.0/16 via 8.9.10.11 dev tun44
Translation:
- All traffic to 44.128.2.0-44.128.2.255 goes to the tunnel and is
encapsulated to 2.3.4.5
- All traffic to 44.128.3.0-44.128.3.255 goes to the tunnel and is
encapsulated to 3.4.5.6
- All traffic not covered by the previous routes, but falling into the
44.128.0.0-44.128.255.255 range is encapsulated to 8.9.10.11
Please observe that the route chosen is the one which defines most
precisely the destination (has the destination in range and has the
biggest prefix length/mask).
These routes are a lot of them, one route for each tunnel, and is the
job of ampr-ripd to receive them via RIP and set them accordingly, in an
automated fashion.
On Mikrotik routers, where there are no P2MP tunnels, each endpoint has
its own tunnel interface with a fixed local and remote address, and are
managed by a script.
So, back to Pierre's question:
- Yes, no mater what your allocation, the tunnel IP needs an IP from
your allocated range and a netmask of /32 (255.255.255.255)
- Yes and No, this local address of the tunnel should be the one of your
router's external interface.
If your router faces the internet directly, the local address of your
tunnel endpoint needs to be your public address assigned by your ISP.
If you are behind NAT (including in a DMZ), this local address should be
the one of your gateway's external interface, ant it will be NATed by
your main router to the public IP.
I hope this clarifies a lot of questions...
Marius, YO2LOJ
On 28.02.2019 23:13, pete M via 44Net wrote:
Hi Marius, I have a few question and I will ask them
in line
1. Add tunnel interface
- Config Tree → add tun44 → Update List
- tun44:
address: <your AMPR gw address>*/32* My allocation is 44.135.51.0/26 So
From what you are telling here I should use: 44.135.51.0/32 ??
description: AMPR GW
encapsulation: ipip
local-ip: <your public gw IP> Is that the IP adress that my ISP provide
me? or is it the IP adress that I want to show to the internet? like 44.135.51.1 in my
case??
remote-ip: *0.0.0.0*
- Press Preview ans Apply
THanks!!
Pierre VE2PF
________________________________
De : 44Net <44net-bounces+petem001=hotmail.com(a)mailman.ampr.org> de la part de
Marius Petrescu <marius(a)yo2loj.ro>
Envoyé : 27 février 2019 03:03
À : 44net(a)mailman.ampr.org
Objet : [44net] Update: EdgeRouter Lite (and probably others) full tunnel setup
Hi everyone,
I updated the instructions for setting up an EdgeRouter as a full AMPR
gateway.
1. Add tunnel interface
- Config Tree → add tun44 → Update List
- tun44:
address: <your AMPR gw address>*/32*
description: AMPR GW
encapsulation: ipip
local-ip: <your public gw IP>
remote-ip: *0.0.0.0*
- Press Preview ans Apply
2. Download your packages from here:
Find the EdgeRouter setup package here:
http://www.yo2loj.ro/hamprojects/Ampr_EdgeRouter.tgz (mips64)
For the EdgeRouterX setup use this one:
http://www.yo2loj.ro/hamprojects/Ampr_EdgeRouterX.tgz (mipsel)
Inside those archives, there is a setup.txt file explaining the next steps.
NOTE: THE SETUP SCRIPT DOES NOT SECURE YOUR ROUTER. YOU NEED TO SET UP
FIREWALL ROUTES YOURSELF.
3. Optionally you can install a status page in the wizzard section.
Download here:
http://www.yo2loj.ro/hamprojects/Ampr_Status_Wizard.tar
I hope this is useful,
Marius, YO2LOJ