The basic idea would be that AMPR to AMPR traffic is a go since it is tunneled directly. Public IP to AMPR is a no-go for tunneled networks. They have a public Gateway IP anyway, so you should use that one for access from the internet.
Marius, YO2LOJ
When you use Echolink from within AMPRnet but want to use a public IP you should be very careful how to implement it. Some people configure an Echolink repeater on an AMPRnet address and then route the traffic to some gateway where this address is translated using NAT.
However, this does not work correctly! The Echolink repeater will register itself with the Echolink system server which is on public internet, so the registration address in the Echolink system is the address of your NAT router. But internally, the repeater has a 44.x.x.x address so when someone from a 44.x.x.x address connects the reply will come from the wrong address and the connection does not go through.
This manifests itself when some other systems are natively on AMPRnet not using NAT. For example, here in the Netherlands we have several repeaters with a true AMPRnet address that is BGP routed, and we also run several Echolink proxies and relays on AMPRnet addresses. In neighboring Germany, the NAT method is often used, where the repeaters have a 44.x.x.x address but connect to the Echolink server via NAT.
As a result, no connections between the repeaters in these two areas are possible, and worse: people using our Echolink proxies and relays cannot connect to German repeaters or users.
It can be solved by not using NAT to translate the Echolink traffic to public addresses, but instead run an Echolink proxy on the gateway system which converts the internal AMPRnet address of the Echolink repeater to the public address of the gateway. Unfortunately only a single proxy can be run per public IP address, so a "normal" gateway with a single external address can only host a single repeater. To solve this, a number of proxies can be run e.g. in a datacenter where an IPv4 subnet is available for them (more and more difficult, of course!). This has now been done in Germany.
The disadvantage of this solution is that all users that are on AMPRnet still connect to the outside address. On a BGP routed AMPRnet network where no proxies or translations are used, local users can connect the repeater directly.
Rob
The easiest way would be to put an Echolink system server on a 44.x.y.z IP... Anybody working on this? This will avoid NAT and proxies, but problem with bandwith and latency staies the same if serveral "44 islands" are connected via tunnels. You then have to consider the bandwith of the tunnels and the performance of the peers.
Micha, DD2MIC
Am 30.05.2016 um 10:01 schrieb Rob Janssen:
(Please trim inclusions from previous messages) _______________________________________________
The basic idea would be that AMPR to AMPR traffic is a go since it is tunneled directly. Public IP to AMPR is a no-go for tunneled networks. They have a public Gateway IP anyway, so you should use that one for access from the internet.
Marius, YO2LOJ
When you use Echolink from within AMPRnet but want to use a public IP you should be very careful how to implement it. Some people configure an Echolink repeater on an AMPRnet address and then route the traffic to some gateway where this address is translated using NAT.
However, this does not work correctly! The Echolink repeater will register itself with the Echolink system server which is on public internet, so the registration address in the Echolink system is the address of your NAT router. But internally, the repeater has a 44.x.x.x address so when someone from a 44.x.x.x address connects the reply will come from the wrong address and the connection does not go through.
This manifests itself when some other systems are natively on AMPRnet not using NAT. For example, here in the Netherlands we have several repeaters with a true AMPRnet address that is BGP routed, and we also run several Echolink proxies and relays on AMPRnet addresses. In neighboring Germany, the NAT method is often used, where the repeaters have a 44.x.x.x address but connect to the Echolink server via NAT.
As a result, no connections between the repeaters in these two areas are possible, and worse: people using our Echolink proxies and relays cannot connect to German repeaters or users.
It can be solved by not using NAT to translate the Echolink traffic to public addresses, but instead run an Echolink proxy on the gateway system which converts the internal AMPRnet address of the Echolink repeater to the public address of the gateway. Unfortunately only a single proxy can be run per public IP address, so a "normal" gateway with a single external address can only host a single repeater. To solve this, a number of proxies can be run e.g. in a datacenter where an IPv4 subnet is available for them (more and more difficult, of course!). This has now been done in Germany.
The disadvantage of this solution is that all users that are on AMPRnet still connect to the outside address. On a BGP routed AMPRnet network where no proxies or translations are used, local users can connect the repeater directly.
Rob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net
I don't know how they do the job... but as all of you can see, also iPAD/iPhone can do it by using my small ampr.org facility :)
73, gus
Mon May 30 07:51:26 2016: Incoming EchoLink connection from IU0GCO (Mario) at 44.137.75.245 Mon May 30 07:51:26 2016: SimplexLogic: Activating module EchoLink... Mon May 30 07:51:26 2016: IU0GCO: Accepting connection. EchoLink ID is 543469... Mon May 30 07:51:26 2016: IU0GCO: EchoLink QSO state changed to CONNECTED Mon May 30 07:51:26 2016: --- EchoLink info message received from IU0GCO --- Mon May 30 07:51:26 2016: Station IU0GCO Mon May 30 07:51:26 2016: Mario Mon May 30 07:51:26 2016: Mon May 30 07:51:26 2016: samsung SM-N9005 User Mon May 30 07:51:26 2016: Mon May 30 07:51:26 2016: IU0GCO is running EchoLink for Android on a samsung SM-N9005, with Android version 5.0. Mon May 30 07:51:26 2016: IU0GCO: EchoLink QSO state changed to BYE_RECEIVED Mon May 30 07:51:26 2016: IU0GCO: EchoLink QSO state changed to DISCONNECTED Mon May 30 07:51:26 2016: SimplexLogic: Deactivating module EchoLink...
--------------
Mon May 30 13:10:57 2016: Incoming EchoLink connection from IU8ABE (NGM) at 44.137.75.240 Mon May 30 13:10:57 2016: SimplexLogic: Activating module EchoLink... Mon May 30 13:10:57 2016: IU8ABE: Accepting connection. EchoLink ID is 940522... Mon May 30 13:10:57 2016: IU8ABE: EchoLink QSO state changed to CONNECTED Mon May 30 13:10:57 2016: Tx1: Turning the transmitter ON Mon May 30 13:10:57 2016: IU8ABE: EchoLink QSO state changed to BYE_RECEIVED Mon May 30 13:10:57 2016: IU8ABE: EchoLink QSO state changed to DISCONNECTED Mon May 30 13:10:57 2016: SimplexLogic: Deactivating module EchoLink...
On 05/30/2016 12:20 PM, Micha Przybilla wrote:
(Please trim inclusions from previous messages) _______________________________________________ The easiest way would be to put an Echolink system server on a 44.x.y.z IP... Anybody working on this? This will avoid NAT and proxies, but problem with bandwith and latency staies the same if serveral "44 islands" are connected via tunnels. You then have to consider the bandwith of the tunnels and the performance of the peers.
Micha, DD2MIC
Am 30.05.2016 um 10:01 schrieb Rob Janssen:
(Please trim inclusions from previous messages) _______________________________________________
The basic idea would be that AMPR to AMPR traffic is a go since it is tunneled directly. Public IP to AMPR is a no-go for tunneled networks. They have a public Gateway IP anyway, so you should use that one for access from the internet. Marius, YO2LOJ
When you use Echolink from within AMPRnet but want to use a public IP you should be very careful how to implement it. Some people configure an Echolink repeater on an AMPRnet address and then route the traffic to some gateway where this address is translated using NAT.
However, this does not work correctly! The Echolink repeater will register itself with the Echolink system server which is on public internet, so the registration address in the Echolink system is the address of your NAT router. But internally, the repeater has a 44.x.x.x address so when someone from a 44.x.x.x address connects the reply will come from the wrong address and the connection does not go through.
This manifests itself when some other systems are natively on AMPRnet not using NAT. For example, here in the Netherlands we have several repeaters with a true AMPRnet address that is BGP routed, and we also run several Echolink proxies and relays on AMPRnet addresses. In neighboring Germany, the NAT method is often used, where the repeaters have a 44.x.x.x address but connect to the Echolink server via NAT.
As a result, no connections between the repeaters in these two areas are possible, and worse: people using our Echolink proxies and relays cannot connect to German repeaters or users.
It can be solved by not using NAT to translate the Echolink traffic to public addresses, but instead run an Echolink proxy on the gateway system which converts the internal AMPRnet address of the Echolink repeater to the public address of the gateway. Unfortunately only a single proxy can be run per public IP address, so a "normal" gateway with a single external address can only host a single repeater. To solve this, a number of proxies can be run e.g. in a datacenter where an IPv4 subnet is available for them (more and more difficult, of course!). This has now been done in Germany.
The disadvantage of this solution is that all users that are on AMPRnet still connect to the outside address. On a BGP routed AMPRnet network where no proxies or translations are used, local users can connect the repeater directly.
Rob
-
'Gustavo Ponza' -
Micha Przybilla -
Rob Janssen