Issue number one. The iOS devices CANNOT see the Qubes instance, but I can add the ip address of my iOS devices to favourites on the Qubes instance and send things to them. I cannot do that on the iOS devices, because I cannot work out the correct IP address (I believe)
You say that’s not an issue… but it’s surely an issue if I cannot send things with an app designed for sending.
Just as a general tip: In order to get adequate help from community/forum, you really need to post more concrete information about
Everything else is kinda poking in the dark.
This seems a bit strange. Normally you either get an assigned IP by DHCP server with a certain lease time, or configured a static IP for sys-net.
As said, it’s fine as long sys-firewall itself has a net qube pointing to your LAN, where the other LocalSend devices are in. This net qube was sys-net in above examples. Proposed script should work regardless of intermediate net qubes.
This is an indication, that your system is properly configured as LAN device, but port forwarding does not work yet.
nft?Related resource: Firewall | Qubes OS
See above point my very first point concerning more concrete descriptions.
Thanks again for you help.
I think I am being fairly concrete from the beginning.
I stated I don’t really understand what I am doing.
I stated that I can favourite and send things from Qubes to iOS devices (iPad and iPhone), but it doesn’t automatically find them.
I stated that iOS devices can see each other but neither can see Qubes, and that I cannot ascertain the correct IP to add Qubes on these devices as a favourite.
I stated what OS and templates I was using.
I stated all I could about my VPN use when asked.
As a bit of a layman, I don’t really know how much more info I can actually give.
There has been no feedback from the apps, no error messages other than just ‘error’ when I guess at an IP from qubes in the iOS interface. I havent used any commands other than what users have kindly offered me.
-As I mentioned already, I created the directory in the location you advised, then used nano to add the script.
-No errors.
-Yes its 4.2, fedore 38 xfce, as I said in the first post.
-Yes
Every time I restart sys-net, and right click on the wifi symbol, the ip address changes
Anyway, thank you for your and others’ free help - I appreciate it even if it’s not coming across very well - English isn’t my first language.
My case:
LocalSend on Windows or Qubes os(with VPN or not) can see Android or iPhone(with VPN or not).
LocalSend on Android or iPhone without VPN can see Windows or Qubes os(with VPN or not), but LocalSend on Android or iPhone with VPN can not see Windows or Qubes os.
If VPN runs on iPhone or Android, LocalSend on iPhone or Android can not see Windows or Qubes os.
Because if mobile device connects to VPN network, LocalSend on mobile device assumes it is in VPN network itself, it don’t see local network.
Its reason is perhaps network design of mobile device, LocalSend is following to its design.
So case of one is normally working of LocalSend, this is not issue.
Your LocalSend on Qubes os is just working same to case of one, so I guessed reason of your issues is VPN on your mobile device.
If your issue is case of two, I think issue of LocalSend or Qubes os, but your issue is case of one, I don’t think it is a issue.
Thank you for clarifying. Even when not using a VPN on iOS, it’s the same result. iOS cannot see the Qubes instance, regardless as to whether there is a VPN active on the iOS device or not.
It’s all fine from my side - sorry if you perceived answers in this way.
If you tried to ping Qubes: IMO it won’t respond to these requests. But cannot speak of iOS here.
And did you execute this script?
hmmm. I don’t know… how would I do that? I think perhaps I have not 
Well, this would explain things 
In sys-net you’d need to execute
bash /usr/local/bin/localsend_forward.sh start
# or if file is executable
/usr/local/bin/localsend_forward.sh start
It’s totally fine to ask these questions here as a beginner - that’s what a forum is for. But granted port forwarding and networking is a bit more advanced topic in Qubes OS (and Qubes OS beging advanced itself!), I’d highly encourage to read first on more basic topics about Linux, Qubes OS, terminal etc. Or grab a friend/colleague which is more knowledgeable of Qubes.
Of course you can try the steps described here, but you should understand their background and don’t blindly follow them. At least don’t flame us in case of accidental bricking your system then 
.
I do know a little about Linux, but I know nothing about networking, and Qubes isn’t normal in this respect. I don’t know anyone IRL who uses Qubes. I have to use forums, but I limit myself to at least the official pages.
I blindly trust to an extent, but I always fully test things before I integrate anything into my wiorkflow.
I tend to use Qubes as standard, and I tend to only really use browsers over apps. I generally dont need to mess with too much stuff, it just works. Due to this, a bricked system doesn’t matter that much, I can reinstall as I have more than several times already! I certainly wont blame anyone but myself.
I assumed that an app to send over a LAN would be easier than this, but I need a better solution than Pair Drop. I had KDEconnect set up on an older Qubes system I had a few years ago, and that was flawless, and I dont recalls needing to mess around like this.
Back to the point at hand. I had originally ran that script, I just forgot to rerun it after you recommended I change script.
I got some errors, I will show you the result of the last command:
sudo bash /usr/local/bin/localsend_forward.sh start
Device "192.168.1.27" does not exist.
Binding TCP '@default:53317' to 'localhost:53317'...
2024/01/21 12:02:55 socat[2724] E bind(5, {AF=2 0.0.0.0:53317}, 16): Address already in use
Error: datatype mismatch, expected IPv4 address, expression has type Internet protocol
add rule ip qubes custom-input ip daddr tcp dport 53317 ct state new accept
~~~~~~~~ ^^^
As I said, you need to run this on every net qube startup - automatically or manually.
I have no idea, how you provoked this error. Even consciously starting script with a “wrong” IP doesn’t print that to me.
This happens, when you try to run start multiple times without having stopped first, as qvm-connect-tcp already occupies this port.
It seems, you set an empty value for variable ip in the script.
@etaz Thank you once again for your help. Unfortunately for the time being I have run out of time to try to solve my issue. I’ll go back to using PairDrop for now, and I’ll delete the LocalSend Qube I made and start afresh from the instructions yourself and @scales. Once I find out the mistake I made and get it working, I’ll mark the solution as solved. Thanks again.
Can you use SimpleX chat?
Desktop app is CLI only a long time ago, but GUI is finally realized, AppImage can run on AppVM based fedora-38-xfce (I have checked).
iOS and Andloid app are already GUI, using is easily.
If you install SimpleX on Qubes os and your Apple devices, you make one time QR code on Qubes os, and your Apple devices read QR code from display of Qubes os, account of SimpleX on Qubes os add into account of SimpleX on your Apple devices.
If your devices can not see each other, you can file send by this method.
I use simplex on my phone yes. Ok ill try that to see if its a one-time fix!
Hello,
I suppose @etaz script exposes LocalSend port 53317 to all qubes connected to sys-firewall. Is that so?
If yes, is there a way to expose LocalSend port only to one dvm template, so that only disposables depending from that template are allowed to use LocalSend?
Perhaps can this be done by just adding a firewall rule to dvm template?
Best
No, you run the script in sys-net and it uses qubes.ConnectTCP RPC service to connect the incoming connections in sys-net to the qube specified in the qrexec policy:
For disposables based on your-localsend-dvm disposable template you can use this policy:
qubes.ConnectTCP +53317 sys-net @default allow target=@dispvm:your-localsend-dvm
Read more about it in the docs:
Many thanks @apparatus for clarifying this matter!
So, I arranged the policy in dom0 /etc… as you suggested:
qubes.ConnectTCP +53317 sys-net @default allow target=@dispvm:dvm-softma-dvm
Regarding the @etaz, I arranged the first two lines of @etaz script as follows:
#!/bin/sh
#if_lan=<your LAN network interface> # see ip -a
ip=192.168.1.226
port=53317
case $1 in
start)
qvm-connect-tcp ::$port
nft add rule ip qubes custom-input ip daddr $ip tcp dport $port ct state new accept
;;
stop)
pkill -f "socat TCP-LISTEN:$port"
nft flush chain ip qubes custom-input
;;
*)
>&2 echo "usage: $0 start|stop"
exit 1
;;
esac
~
Starting the script, using sudo, I get the following response:
Binding TCP '@default:53317' to 'localhost:53317'...
But LocalSend does not connect with the other machines on the same network, neither running it into the disposable template nor into the dispVM depending from it.
So I tried to simplify the policy as follows:
qubes.ConnectTCP +53317 sys-net @default allow target=dvm-softma-dvm
Now, using the dvm template I got an alert in the upper right part of the screen;
"Denied: qubes.ConnectTCP
Denied qubes.ConnectTCP +53317 from sys-net to"
As likely LocalSend does not connect.
So any idea what may be wrong here?
What’s your dvm-softma-dvm net qube?
Does it have access to your LAN e.g. connected to sys-firewall and not to sys-whonix/sys-vpn/offline?
Did you start it in sys-net?
Many thanks for your very prompt reply
sys-firewall
yes
Yes
And, to be sure, every time I edited the policy, I restarted the machine, even if it should not be necessary I suppose.
I think it’s configured correctly.
Maybe you need to configure firewall on your other device with LocalSend.
Try to configure your LocalSend to work in an app qube first before trying to do this in disposable.