Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pick different oC server hostname/IP depending on network (inside LAN vs on internet) #203

Closed
moritzthecat opened this issue Dec 23, 2012 · 25 comments

Comments

@moritzthecat
Copy link

moritzthecat commented Dec 23, 2012

Objective: enable fast access/sync while being inside local network and automatically use dyndns WAN sync while being abroad

Reference forum thread: viewtopic.php?f=14&t=3114&hilit=local+network

Ubiquitous Computing is one of the drivers for applications like OC. In combination with hosting an own OC server (e.g. on a NAS) one of the typical scenarios is that mobile users of this particular OC server may be inside of the high performance local network or while traveling having access through Internet WAN, which is expected to be somewhat slower.

A) While traveling or being abroad typically DNS/dyndns is used by the clients to access the hosted OC server e.g. on a NAS in the LAN

B) While being at home (inside the local network) it would be desirable to benefit from the faster local access instead of using the external DNS/dyndns IP address, which works (thanx to NAT lookback supported by most routers) but is somewhat slow compared with the supported local speed.

The Feature Request I have in mind is an additional connection priority option to access the local OC server directly from inside LAN if available, as well as to define the DNS/dyndns path to the OC server. So if the OC client is able to use the preferred and fast local path to the OC server it will use this connection instead of the DNS/dyndns one. Although while traveling, the same setup then determines that there is no direct path avail. and thus will use the dyndns connection.

Please let me know in case there are already ways implemented in OC providing this functionality, but keep in mind that mobile devices such as smart phone may have limited configuration possibilities at OS level. This is why I consider this to become a vaild feature request to be covered by the OC Clients instead of the OS level.

BTW: having looked to other cloud sync solutions - this is referred to as "fast LAN sync" feature. Hope this helps.

Looking forward to your comments and suggestions.

Merry Christmas


Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@snowjet
Copy link

snowjet commented Jan 1, 2013

I have achieved what you require through an internal DNS server.

I run an internal DNS server (bind) which hosts internal domain entries for my domain within the LAN. This way when my laptop connects to the LAN it will get the internal OC server address and when it is roaming outside my LAN it receives the public OC server address.

This is my stop gap solution until ownCloud gets Lan sync.

Hope it helps.

@moritzthecat
Copy link
Author

Thanx to snowjet - this looks an excellent idea.

It would be very effective if this internal DNS-Server could be run on the WAN/LAN gateway router which is 24/7 online anyway. I do have a linux based FritzBox and have looked up the corresponding forums where the recommended solution is to add the required mod using iptable commands.

Are there other routers that might have a built-in feature as required? As more cloud based services are used and not all of them are expected to have an optimized WAN/local acccess support, this might be a nice feature for the WAN/LAN gateway devices.

@zatricky
Copy link

The internal DNS server method is certainly a good stopgap - however the "right" way to do it within OC would probably be to use the same or similar mechanism that #230 might use.

Another possibility would be to have a list of alternative hostnames with priorities. This could even aid in future developments for multi-server cloud support.

@etiess
Copy link

etiess commented Sep 13, 2013

Hello,
Is there any progress on thi topic? I looked into my rooter, but it's not possible to change the DNS on my router :-(

@thenewnano
Copy link

@etiess you don't have to change the dns, you just define a hostname, which happens to be the same as the dyndns host name whatever.whatever.com , so the router will not ask internet provider for the address but provides it itself.

@etiess
Copy link

etiess commented Jul 14, 2014

Thank you, I observed that indeed

@animalillo
Copy link

This is a must, speeds on LAN are really slow for what they could be, and that is a pain sometimes

@christianrj
Copy link

I configured this scenario last week and the results are very good. Our Owncloud server is hosted on our intranet.

For this, you will need two IPs on the Owncloud server (local + internet), some static route rules configured and a local DNS server on the intranet.

When our users are on the office, they will use the the intranet to sync. If they are outside, they will use the internet. Everything automatic and transparent for them. Works very well.

@guruz guruz changed the title Support optimized LAN/WAN OC server connection performance Pick different oC server hostname/IP depending on network (inside LAN vs on internet) Aug 29, 2014
@mvysny
Copy link

mvysny commented Sep 2, 2014

If you do not have DNS domain registered, then this approach (named Split DNS) is not viable, unfortunately. You cannot simply add entry to /etc/hosts and override this setting with your home DNS, as /etc/hosts stuff is resolved first and your DNS setting is ignored. Also, this requires some technical skills from users and this would probably scare them away :)

We discussed this matter at bug #2100 and the outcome is that perhaps the best and easiest (easy to implement in owncloud-client) option for now is to provide two IPs - one for server access on LAN, other being a public IP for accessing the server remotely.

Fast LAN sync is probably be something else: in Dropbox, this means that clients sync themselves on LAN with minimum server syncing. But this got me thinking - what if client could auto-discover (by broadcasting) that the server (identified by UUID or some other pre-shared secret, perhaps a certificate?) is present on LAN?

@ImTheDeveloper
Copy link

This would be a really useful feature

@DoNck
Copy link

DoNck commented Jan 26, 2015

👍 That would also adress bad resolution problems with some buggy home routers see owncloud/android#865
I think enabling the user to provide coma separated URLs would help users a lot without complexifying the GUI.

@danimo
Copy link
Contributor

danimo commented Jan 26, 2015

without complexifying the GUI

How does a second host name field not make the GUI more complex? :-)

Also, what algorithm do you suggest? First look up the internal name, and if that fails, try the external one? What if the internal resolves by chance because there is another host behind it on another network? Many people will also not have HTTPS configured internally, so that would even open up an attack vector unless we force HTTPS in both cases if the external one is open.

I'm not saying it's hard to implement, but it's difficult to get right without compromising security and overall stability. I'll gladly help if someone needs assistance implementing this feature, but I'm afraid it's unfortunately not very high on our to do list.

As you can see with other features like SSL Client Certificates or the right click integration for file managers that will be part of 1.8, we're happy to work on patch creation with whoever is willing to step up.

Please don't respond with 👍's though, they will not change our main priorities. Volunteering, and be it just by outlining the feature more specifically, would be very much appreciated.

That said, those "buggy routers" are not buggy but simply have hair pin NAT disabled for efficiency. Most of them have an option that turns it on. Maybe those who do not feel comfortable writing code could contribute to our documentation?

@DoNck
Copy link

DoNck commented Jan 26, 2015

Sorry for apparently wrong usage of the thumbs up symbol, it seems to have a reserved usage on github that I did not know about. I didn't want to be impolite, I just meant it seems a good idea to me.

May be I can propose some patch or improve documentation, but we first have to agree on what to do, right ? "outlining the feature more specifically" as you said.

GUI thing clarification: I proposed keeping using one field, but allowing coma separated values. Not adding an extra field. This way OC could adress the issue some of us encounter without changing anything to the GUI of "lucky" users.

Regarding security, specifying http://<ip_adress>/owncloud URLs si currently being allowed by the android app without any warning (I just checked). It works. It is risky.
Your point about internal http and external https usage is very intersting and kind of matches my issue with the router. How to actually use such a setup with the android client ? Are you thinking about an option like "Allow http method in case detected SSID and / or AP Mac Adress are matching my trusted network" ? These are not proofs but yeah some people might like it better than forcing https on internal.

In any case, displaying a warning when SSL is not enabled would make sense.

Talking about the doc, is there someting specific you want me to document ? Just give me a pointer and I can give it a try.

@strugee
Copy link

strugee commented Jan 28, 2015

Sorry for apparently wrong usage of the thumbs up symbol, it seems to have a reserved usage on github that I did not know about. I didn't want to be impolite, I just meant it seems a good idea to me.

Don't worry about it, you weren't really being rude. The problem wasn't your usage of the thumbs up symbol; the problem was the fact that you're basically adding noise to the issue. (Meaning, comments like "+1", "I'd really like this feature", etc. don't actually help move the issue forward, they just create more email.)

Regarding security, specifying http:///owncloud URLs si currently being allowed by the android app without any warning (I just checked). It works. It is risky.

This isn't justification for implementing insecure behavior in the desktop client. It just means that someone should file a bug against the Android client.

@Enoch247
Copy link

I agree with what others have said about DNS. I don't think it would be smart for owncloud to support this kind of functionality. It is a problem best solved at a lower layer.

A long time ago, I disabled my router's dns/dhcp services and run dnsmasq on my home server instead. It resolves "example.com" and "www.example.com" as cnames pointing to "server.example.com" (which resolves to 192.168.1.xxx) Externally, Godaddy resolves "server.example.com" and "www.example.com" as cnames pointing to "example.com" (which resolves to my router's WAN IP).

I did this so that file transfers over ssh could go at full speed when at home without me having to do anything special like switching ports or server names. When I setup owncloud years later, it just worked. It also works for FTP and plain old webDAV clients connecting to owncloud.

@zatricky
Copy link

Contrary opinion here. DNS is a good stopgap and I do think supporting this kind of functionality is a good idea. But I also don't think the concept here of having network-specific settings is the right way to go.

Two things that could satisfy the needs of the OP:

@SA0TAY
Copy link

SA0TAY commented Mar 18, 2016

Due to the aggressive DNS caching in Android, split-horizon DNS isn't really usable in this situation. I should know; I have an odd setup in which, due to the nature of macvtap, the global IP can't be reached from within the local network, as well as the reverse. So on my wireless network, the public IP address is useless. So I can't even reach my ownCloud server from my phone when it's connected via WLAN.

@plinss
Copy link

plinss commented Mar 21, 2016

Agree with @konaya, client also has overly aggressive DNS caching on OSX. When transitioning from internal LAN to WAN or when on WAN and transitioning to/from VPN the sync client tries to connect with previously cached IP address, even though the DNS name now resolves to a different address. Other apps on OSX, like Contacts and Calendar get the proper IP address immediately when switching networks. Generally takes quitting and restarting ownCoud sync to make it work. Client should either not cache IP address or flush cache when network connection changes.

@guruz
Copy link
Contributor

guruz commented Mar 21, 2016

We could switch QDnsLookup instead of letting Qt do the lookup (which caches it for 30 sec or so..)

@Enoch247
Copy link

@konaya, for what it's worth, I recently learned that Google sets Android phones to always use their DNS servers, regardless of what your DHCP server tells your device to use. If you change this, it may fix your problem.

@gaining
Copy link

gaining commented Sep 23, 2016

I'm late to this discussion but has this already been implemented, if so how? I somehow converted my whole family and few friends to using owncloud hosted on my home server, all is great but we'd like to use the lan's speed when home and wan (internet) speed when out.

@michaelstingl
Copy link
Contributor

Please run dnsmasq somewhere in your home network and point to this host in your routers DNS settings.

Here you can find more information:
https://wiki.debian.org/HowTo/dnsmasq

@SA0TAY
Copy link

SA0TAY commented Jul 30, 2018

@michaelstingl So are you flat-out ignoring the fact that several people, including me, have reported that the aggressive DNS caching on Android and OSX effectively neuters that very solution, or are you just in the habit of not reading the comments on tickets before closing them?

@michaelstingl
Copy link
Contributor

I follow this issue and #5506 for a long time and read it very carefully. But I also don't see this on the roadmap for the next time. If someone would like to contribute, we can open the issue anytime.

I don't like the idea of building things because other things are broken. If the root issue is wrong DNS caching, it should be fixed first as @guruz mentioned in #203 (comment) .

@Thelvaen
Copy link

Thelvaen commented Apr 2, 2020

Please run dnsmasq somewhere in your home network and point to this host in your routers DNS settings.

Here you can find more information:
https://wiki.debian.org/HowTo/dnsmasq

Yeah sure can do that on corporate network without issues when there's no split horizon DNS because .intra vs .extra in the URL is the standard ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests