30 May
2016
30 May
'16
9:01 a.m.
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
30 May
30 May
11:20 a.m.
New subject: AMPRNET katency in VOIP connections ?
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)
_______________________________________________
--
Beste Grüße von
Micha
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(a)hamradio.ucsd.edu
http://hamradio.ucsd.edu/mailman/listinfo/44net 
1:12 p.m.
New subject: AMPRNET katency in VOIP connections ?
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
>
>
2894
days inactive
2894
days old
2 comments
3 participants
participants (3)
-
'Gustavo Ponza' -
Micha Przybilla -
Rob Janssen