I'm trying out VirtualHere for one of our Remote sites. It looks like exactly what we need for an existing Pi3+.
The VirtualHere server I'm running is the generic ARM build for the Pi:
'VirtualHere USB Server for Linux (ARM) <-- Raspberry Pi, pi2, pi3,pi4,BeagleBone, Odroid, Angstrom, & any ARM 32-bit based Android'
We have a Virtual Private Server with a static IP, which hosts an OpenVPN client. We are using the UFW firewall, and I have forwarded 7575 as follows:
0 DNAT tcp -- eth0 any anywhere [static vps ip address] tcp dpt:[lan ip address]
tcp dpt:7575 to:[lan ip address]
I have set up the VirtualHere client with a hub as follows:
[static vps ip address]:7575
The router at the remote site is running an OpenVPN client, and I have forwarded tcp 7575 to the Pi's local IP address.
Other udp and tcp ports forwarded through the virtual private server and router are working.
But all I get is the can't connect message:
INFO :Could not connect to [static vps ip address]:7575
If I connect the Pi directly to my local network, everything works great.
It seems I'm missing some other setting, but I don't know what to try next.
Thanks very much.
Don Sayler
.
I dont do network debugging sorry.
Virtualhere only uses TCP port 7575 (and UDP 5353 if you use auto-find) so...there must be something blocking that port (e.g you might have opened only one way e.g in bound tcp port instead of both ways) . It definately works via OpenVPN as lots of users use this.
Have you find a solution ?
Have you find a solution ?
I have the same problem with VPS and Openvpn
The connection with the port 7575 is ok with telnet test (telnet IP 7575 over openvpn)
But virtualhere client can't access to the server over openvpn
For information directly it's ok (without openvpn, on the direct IP address)
tcpdump for the two
tcpdump for the two interfaces, see below.
Ok for direct interface enp1s0
Bad for VPN interface tun0, the virtualhere don't answer
sudo tcpdump --interface enp1s0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on enp1s0, link-type EN10MB (Ethernet), capture size 262144 bytes
*19:19:51.745817 IP ..56881 > zbox.7575: Flags [P.], seq 3170625927:3170625968, ack 1534734351, win 8208, length 41
19:19:51.746138 IP zbox.7575 > ..56881: Flags [P.], seq 1:42, ack 41, win 501, length 41
sudo tcpdump --interface tun0
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
19:09:28.032373 IP vps-xxxxxxxxx.ovh.net.64042 > zbox.7575: Flags [S], seq 3235262456, win 64240, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0
19:09:29.039433 IP vps-xxxxxxxxx.ovh.net.64042 > zbox.7575: Flags [S], seq 3235262456, win 64240, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length 0
19:09:31.227775 IP vps-xxxxxxxxx.ovh.net.64042 > zbox.7575: Flags [S], seq 3235262456, win 64240, options [mss 1260,nop,wscale 8,nop,nop,sackOK], length
.
"I dont do network debugging sorry. "
Ok, but is it possible to use
Ok, but is it possible to use virtualhere over Openvpn ???
.
"It definately works via OpenVPN as lots of users use this."
Ok, but it don't work with
Ok, but it don't work with standard commercial OVH VPS Openvpn solution.
MTU problem I think, I investigate to find what I must modify.
Thanks
Good ...
Good ...
A big mistake for me, I receive on the tun0 interface, Virtualhere respond on eth0.
A bad iptables on my Openvpn.
Excuse me. Now it's very well
.
OK yes it always is a mistake on the customer side, thats why i dont bother debugging customer network issues anymore :)