You are here

More than 1 tunnel server node

16 posts / 0 new
Last post
w8erw
w8erw's picture
More than 1 tunnel server node

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

nc8q
nc8q's picture
Migrating a tunnel server.

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

w8erw
w8erw's picture
Home Router

The router is a Linksys WRT1900 which should have the capability.  The other issue involved is addressing the clients remotely which likely would not be possible.  Maintaining the tunnel connection while doing the necessary editing could be a problem.  Once the connection was lost, if the reconfiguration was not yet complete, remote admin would cease.  I can see this being a table top exercise until it can be proven to work.

WU2S
WU2S's picture
Multiple tunnel servers

Yes, it is possible to have more than 1 tunnel server on your internet connection.
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.

w8erw
w8erw's picture
Second Hostname

I assumed a second DNS host name would be required which I do have.  The gnarly part would be in editing the configuration files and if that could be done remotely with the clients.  Good to know it is possible.
 

KE2N
KE2N's picture
2nd server same internet connection

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:

root@KE2N-HAPac-1:~# telnet 192.168.1.86 5526
VTUN server ver 3.X 03/22/2019

but not from outside.

C:\Users\Ken>telnet 192.168.1.86 5526
Connecting To 192.168.1.86...Could not open connection to the host, on port 5526: Connect failed

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:4

I don't know where to go from here. Pointers anyone?




 

nc8q
nc8q's picture
Fun with tunnels

Would running tcpdump from either/both ends help?
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.


 

KE2N
KE2N's picture
dump

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

root@KE2N-HAPac-1:~# tcpdump port 5526
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
01:42:17.041239 IP 192.168.1.19.57873 > 192.168.1.86.5526: Flags [S], seq 3501458969, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
01:42:17.041455 IP 192.168.1.86.5526 > 192.168.1.19.57873: Flags [R.], seq 0, ack 3501458970, win 0, length 0
01:42:17.543320 IP 192.168.1.19.57873 > 192.168.1.86.5526: Flags [S], seq 3501458969, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
01:42:17.543532 IP 192.168.1.86.5526 > 192.168.1.19.57873: Flags [R.], seq 0, ack 1, win 0, length 0
01:42:18.045269 IP 192.168.1.19.57873 > 192.168.1.86.5526: Flags [S], seq 3501458969, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
01:42:18.045464 IP 192.168.1.86.5526 > 192.168.1.19.57873: Flags [R.], seq 0, ack 1, win 0, length 0

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.

 

KE2N
KE2N's picture
found more

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?

 

KE2N
KE2N's picture
options

I suspect that one or more of the "vtun" files needs to have something like 

config options
           option port 5526

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

 

KE2N
KE2N's picture
to close out

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.

w8erw
w8erw's picture
Tunnels

I agree, the proper sustainable RF links are ideal.  In the interim, tunnels help demonstrate capability and sell the concept.  It's all a learning process and much like building your own equipment, working with the AREDN network and realizing success is fascinating and creative.  Often making something work when it wasn't supposed to is as much fun as using it once you have made it work.  Isn't that what we do...   

K6AH
K6AH's picture
Randy's use of the phrase... 

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

w8erw
w8erw's picture
Tunnels

Andre, I much agree.  My earlier reference to making things work that were not supposed to was directed more at the way we Hams approach a problem and not so much as using tunnels when we understand they will likely fail under the stress of a disaster situation.  In general I believe our current situation where cellular has replaced much if not nearly all of the wired telephone network, we have opted for convenience over reliability.  Cell phones really suck and the promises that were made early have never been realized. It's gotten better and likely that will continue but as in most anything else, there is a time and place.  The reality of the situation is always important to remember.

nc8q
nc8q's picture
switch existing tunnel connections to a new node

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

w8erw
w8erw's picture
Tunnel connections migrating to a new server node

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

Theme by Danetsoft and Danang Probo Sayekti inspired by Maksimer