I've not seen this spoken to. However, is it possible to have more than one node operating as a tunnel server on the same internet connection. It would seem not in that the tunnel server node uses port 5525 exclusively. A possible reason to do so would be the desire to switch existing tunnel connections to a new node, perhaps to a 64Mb node from a 32Mb node while maintaining existing connectivity. Both new and old tunnel serving nodes would need to be fed from the same home router to do so. My logic says not under normal circumstances without provision for additional port forwarding (5525, 5526), a different port for each tunnel serving node. Any thoughts? Thanks, Jim W8ERW
Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer
Hi, Jim:
Key words/phrases: possible, while maintaining existing, home router, normal.
Good question. I think it is kind of possible.
It is possible to have a firewall/router port-forward based on inbound IP address.
It seems that a new-node's tunnel server 'Network' port can be modified to 172.31.X.Y to match the existing old-node tunnel server.
However, you specified 'home router'.
So, I assume 'no' as it may not be not 'normal' for a 'home router' to port-forward based on both port and inbound IP address.
I am unsure that if a node's tunnel server's 'Network' modified address is retained over a reboot or sysupgrade.
If a tftp factory-bin upload occured, the owner would need to reprogram the modified tunnel 'Network' address.
Maybe not 'normal'.
I think that there is a maximum of ten (10) tunnels allowed, so which is easier:
copying the tunnel client's node names and modifying the new-node's tunnel 'Network' address,
which maintains 'existing connectivity'.
or
copying the tunnel client's node names and
getting up to ten neighbor tunnel clients to edit their node's tunnel configuration,
which momentarily breaks 'maintaining existing connectivity'.
HTH, Chuck
It requires using another port number, say 5526, for the second server, and another hostname for your second dynamic DNS gateway on DDNS or NoIP.
It also requires that you manually edit both your tunnel server configuration file and the client's tunnel configuration to use this new port number.
I am doing this with 2 tunnel servers as an extended experiment.
As always, tunnels are not recommended for production emergency communications networks.
I am trying to add a second tunnel server here using port 5526 and a HAPac lite running 3.19.3.0.
I have a second DDNS name for my internet connection and am using that for the Tunnel Server DNS Name.
I have edited the file /etc/init.d/vtundsrv to put in port 5526 and added port forwarding in the home router for the IP of the new node.
Using top, I can see vtund[s] is running and listening on port 5526
But the new server does not connect to a client (which also has its config file modified for 5526).
Not only that, it seems not accessible from the network.
I can use the trick of telnet -ing to the address and port of vtund with the first tunnel node on my system.
For the second/new node, I can telnet from within the node itself:
but not from outside.
so it seems like there is something in the node's firewall that is not allowing this. In fact (if relevant) ifconfig is showing a large percentage of dropped packets:
eth0 Link encap:Ethernet HWaddr CC:2D:E0:29:A6:69 inet addr:192.168.1.86 Bcast:192.168.1.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:4846 errors:0 dropped:1187 overruns:0 frame:0 TX packets:1558 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1299336 (1.2 MiB) TX bytes:390311 (381.1 KiB) Interrupt:4I don't know where to go from here. Pointers anyone?
tcpdump port 5525
tcpdump port 5526
tcpdump portrange 5525-5526
Also, I think there is a version of 'nmap' for windows.
That tool may help.
well - here is the result of a tcpdump on the second tunnel (192.168.1.86) while trying to telnet to the node from windows
it would seem that the Windows PC sends the same request 3 times and gives up.
I suppose this means that it did not hear the response from the node/vtund or is not happy with what it heard.
I do not know how to interpret the data,
If I telnet from within the node, the data does not pass through the Ethernet port, so there is nothing to see.
A tcpdump on the first tunnel (the one that works) shows reams and reams of data flying through.
NMAP 7.7 for WIndows ("zenmap") does not find much of anything with the AREDN load - only port 113.
In the support data I found where the firewall has 5525 hard-coded in it somehow
I manually added a line in IPTABLES to accept 5526 as well
-A zone_wan_input -p tcp -m tcp --dport 5526 -j ACCEPT
however I still see this (in the support data printout):
vtunduciport=$(uci get vtun.options.port 2>/dev/null)
vtundport=${vtunduciport:-5525}
and I don't know what to do about it
Hello - developers?
I suspect that one or more of the "vtun" files needs to have something like
in it ( Google tells me that I asked a related question on this back in 2015 - good grief).
I tried the above but still getting 5525 in the IPTABLES readout ... so something is not working. It seems that get vtun.options.port does not return anything
I finally found the file - etc/local/mesh-firewall/02-vtund and changed that.
Now I can telnet from outside the node :-)
Tomorrow i will tell you if the client access works!
good night
the feature for an optional tunnel port does not work and apparently the developers have no interest in it.
The simplest thing to do is to configure your internet router to do port address translation so that you have different ports on the outside and all your tunnels servers use 5525 on the inside. So no server program mods required.
Clients will have to modify one line in one file:
/etc/init.d/vtund
change the line where it says
config_get port "$cfg" port "5525"
That's all.
For WU2S
G'day.... I am trying to set up a second tunnel server. Would you be able to send me the file name and the portion of code outlining the your change of port to 5526?
Best regards .... Martin
/tmp/vtun/vtundsrv.conf
The first lines should look like:
options {
port 5525;
timeout 60;
Remember to port forward the new number you assign to the tunnel server you want to reach.(the server's IP address)
Randy's use of the phrase... "production emergency communications networks" means one that is ready to serve the needs of hams supporting disaster-services organizations. When tunnels form links within that network they give the impression the network is more comprehensive than it actually is. It also results in a false sense of readiness.
There's nothing wrong with using tunnels... just be careful how you present/sell the network and let everyone know that these links (and the nodes they connect in) likely will not be running during a disaster.
Andre
Hi, Jim:
To migrate a tunnel to a new node could be done by editing the new node's tunnel network ('Tunnel Server Network')
to the same network range as the old tunnel,
copy the old client none names to the new node matching 'Client', 'Pwd', and 'Net',
then edit your router to port forward to the new nodes LAN IP address.
If the old-tunnel and new-tunnel used static IP addresses, then there would be no need
to re-configure the router. Just edit each tunnel's address (/admin: WAN: DHCP, static, disabled).
I think this would be a seamless migration.
On a NS-M5-XW, with 'Keep Settings' selected,
I edited the tunnel server network to 172.31.0.0 and did a sysupgrade.
The edited network base address was retained.
HTH, Chuck
This is the process that I had envisioned although I had no idea if it were possible to do so. Aside from editing the port and other parameters in order to establish effectively two servers which seems to be a lot more difficult, this is a more simple approach.
Thanks,
Jim
W8ERW