Very TNX Rob. I conceptually understood the possible scenarios and I'll seek the method to force the 192.168.x.x or the 10.x.x.x towards the repeater...
However it seems to me that the BGP routing of the 44.x.x.x IPs remains the best and clean solution for any kinda problems.
So, coming back to the original item on the subject: if, at least, my main server IPs 44.134.32.240 and 44.134.32.233 were full published and routed over the internet by UCSD any problems here should magically solved :)
73, gus
On 05/31/2016 11:34 AM, Rob Janssen wrote:
(Please trim inclusions from previous messages) _______________________________________________
The fact is that, actually the repeater is networked to the EchoLink server and this can be obtained ONLY by using the commercial IP number, i.e. IP address 79.47.199.234.
Look at our repeaters, e.g. PI2NOS It is registered on the Echolink system using its own address 44.137.72.130 (pi2nos.ampr.org). Therefore this problem does not occur here.
the incoming IP results 44.137.41.97; so I understand that the internet server act as the real gateway in a similar way as our ampr.org gateways. It function very OK!
Yes, for "normal traffic" it works OK. But not for Echolink. This is because Echolink has a directory server that registers your repeater by IP address, and this address does not match the actual address.
When you get connected by someone from plain internet, it works OK because the route back is through the same NAT router, where you have defined port forwarding for the 5198 and 5199 ports, and the users sees the same translated address as the Echolink system registered.
However, when I connect from my address 44.137.41.97, the repeater or another part of the system thinks it is being clever and routes the traffic through a IPIP tunnel, the address does not get translated, and the connection fails.
The quick way to solve it is to give your repeater some RFC1918 address (10.x.x.x, 192.168.x.x) so its traffic is always forced through the NAT router. Alternatively, you can setup some policy routing so the Echolink traffic is always sent to the NAT router, not routed directly. Then you can still use AMPRnet on the same computer for other things.
The way we solved it here is by applying for BGP routing of our subnet, so our net-44 traffic is routed directly on internet and it is no problem to run an Echolink repeater on it. (the subject of this thread: will routing through UCSD cause problems with VoIP. yes it will, but we don't route through UCSD so we don't have that problem)
Rob
44Net mailing list 44Net@hamradio.ucsd.edu http://hamradio.ucsd.edu/mailman/listinfo/44net