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
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@mailman.ampr.org de la part de Marius Petrescu marius@yo2loj.ro Envoyé : 27 février 2019 03:03 À : 44net@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.
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
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.
- 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