My Allstar node used VPN and the central server got it wrong IP

The last Sep 20 I sent to helpdesk this message and never receive the answer, I hope somebody here can help me:

I have a VPN with port forwarding service and I have a problem with my dedicated IP address, the central server used nslookp to discover the ip, and got sometimes my dedicated ip and sometime my provider ip, example

root@REPDOM46818:/home/repeater# cat /var/lib/asterisk/rpt_extnodes | grep 59201
root@REPDOM46818:/home/repeater# cat /var/lib/asterisk/rpt_extnodes | grep 59201

I the ip got it by central server is 186… I cannot connect to any node with this reason:

WARNING[3886]: app_rpt.c:23293 rpt_exec: Node 59201 IP does not match link IP!!

How can I do to solve this problem? How can I tell central serve that my ip It is that of the tunnel and not that of the supplier

My dedicated IP is (tun0) and my provider IP is

This is my ifconfig

inet netmask destination
unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 100 (UNSPEC)
RX packets 7324 bytes 3274077 (3.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 9256 bytes 1038941 (1014.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

Isn’t the whole reason to use a VPN to hide your IP address?

Unfortunately my provider cannot permit access to router so I have all ports closed,and the only way to open ports is using a vpn with port forwarding, i use a dedicated ip at the end of the tunnel, but the nslookup got it the provider ip instead the tunnel, sorry my bad english

From a quick read of this, I think your outbound traffic (from the allstar system) is going over your ISP and not the VPN.

You need to check your routing, you can use tools like telnet to see the path taken.

Hey good afternoon

Ok how can I do to routing over tunnel ?

Are you able to provide the output of ip a and ip r here? Please sanitize any private data.

Sorry I know understand what you means

No problem, you need to run the command ip r and send the output here.

root@pi-asl:/home/repeater# ip r via dev tun0
default via dev tun0
default via dev eth0 proto dhcp src metric 202
default via dev wlan0 proto dhcp src metric 303 dev tun0 proto kernel scope link src via dev tun0 via dev eth0 dev eth0 proto dhcp scope link src metric 202 dev wlan0 proto dhcp scope link src metric 303

Hey, okay that looks good. You are routing your default traffic over the tunnel.

Does your VPN tunnel port forward UDP 4569?

yes, but sometimes the Allstar server got my provider ip instead my tunnel ip, so when the distribution will do, the wrong ip are stored in all nodes database

It looks on the surface that when you are registering, your native IP is being used, thereby making all the nodelists incorrect when you try to connect using the VPN IP and they will not allow the connect.

Somehow, you need to force the use of VPN IP during registration. Then the nodelist data will be correct for inbound and allow the outbound connects you make.
Or don’t use the VPN on the server. Perhaps DDNS.

If the outbound connection attempt does not match the ip data in the targets nodeslist file,
it will be refused.(security)

You can look at that yourself for testing /var/lib/asterisk/rpt_extnodes
and know when you have it correct.

To add to Mikes detailed response.

You might want to delay the start of Asterisk. This should allow time for the VPN to establish before you start to send packets out. If this works you may want to write a script that checks the default gateway is correct before Asterisk starts.

OK thanks for the answer and I know all that you guys explain to me and that’s what I need so

how can I do that? is my question from beginning

I don’t use VPN, so I can only guess at what might be a remedy.

And one method to try is to wait long enough for the vpn to settle after boot,
then go to asterisk cli>
asterisk -rvvv

And then reload the node

where it will re-register in the process of that reload.

Outside of that, you would need to halt loading asterisk until the network has fully settled with your vpn.
You might need to wait up to 10 more minutes to test and the vpn ip to propagate the nodeslist.

So, I can only present a work-around for the issue. And the above can be done with a startup macro and script if you were trying to make it more permanent.

It is worth a test to see if it gets you there and then try better methods.

OK thanks for the help