Question

I want to make the twiki running on my lan at home available to the internet.
I'm sure other people have run into this and if there is a "canned" siolution I'd be glad to hear it.

However I have an idea - a few actually - but would like to discuss them. This seems to me to be more of a support issue than a Codev issue.

In the following, I'm going to use made-up but plausable domains and IPs.

Setup

Let call the internal DNS's base 'antonlan.home' (yes I know its not a TLD but if you can't fudge DNS like that why play in this pool?).
Lets call the single external address from the internet 'antonhome.dyndns.org'.
_Of course these don't really exist in any name space, they are just examples._

OK, that and DNS and we don't have to actually worry about the IP addresses

• Home based LAN beind a Linux+IPTables firewall
• Uses NAT to handle single DSL internet address.
• DNS server running on LAN that resolves LAN addresses and forwards other requests to a cahcing server running on the firewall.
• Twiki running on server on LAN.

This is one possible starting point.

• The firewall redirects 'antonhome.dyndns.org:8080' to 'twikiserver.antonlan.home:80'

Problems

In lib/TWiki.cfg the URLHost is set.

• For internal access this is 'http://twikiserver.antonlan.home'
• For external access this is 'http://antonhome.dyndns.org:8080'

So there is a conflict.

Resolution Ideas

Dual Set-up

This has two 'entrypoints'

• For internal access this is 'http://twikiserver.antonlan.home/twiki/index.html'
• For external access this is 'http://antonhome.dyndns.org:8080/index.html'

These correspond to two copies of lib/TWiki.cfg and hece two copies of lib/ and bin/.
The other enties in TWiki.cfg that point to the data are the same.

Virtual Hosts

Apache has this capability. Late-model browsers not only issue the GET but also say what the domain is. Apache can do things with this, so supporting more than one "domain" on a single IP.

However I don't see how this solves the TWiki.cfg problem. Presumably those two virtual domains will still need seperate lib/TWiki.cfg.

And yes, I've seen InternetAndIntranetAccessAndHtaccess - I'm sure this is a common enough situation to warrant a cookbook solution.

-- AntonAylward - 01 May 2003

Answer

Hi Anton! This sounds close to what I would also want to do. Your approach sounds reasonable enough to a layman like myself. I just have one question: If http://antonhome.dyndns.org:8080/index.html is your link from outside your lan, and the machines on your lan have Internet access, then why not simply use that same address internally? That way you only need one setup, namely the external one. I can't think of any reason to use a different one internally than externally.

-- TorbenGB - 06 May 2003

I had a look at the TWiki code recently on seeing this request, and it seems that $urlHost is only used in a very few places - if you patch TWiki to avoid using it there, IMO it may 'just work' with two different URL host parts. You would also need to check the templates, and ensure that the URLs without the host part are identical.

-- RichardDonkin - 06 May 2003

TWiki should pick up different protocol:host:port portions of the URL just fine, e.g. you should be able to use two different URLs as long as the URL path is the same. TWiki gets the protocol:host:port portion from the cgi environment and reuses that for the links it produces. The reason for the $defaultUrlHost setting in TWiki.cfg is to account for the cases where scripts are called not as a cgi script, e.g. mailnotify.

-- PeterThoeny - 06 May 2003

Torben, I'm glad I'm not the only one

To answer you question, pobanbly for you and me it would work, but its not a general solution. What it invovles is the client - on the LAN - going out to the outside port of the firewall (which is that public address) and all the way back in. Your firewall rules may prevent it.

However some corporate settings may:

• Have a per connection licensed firewall
• Want IP-based "automatic" authentication for LAN users but explicit passwords for external users.

There's also a whole set of situations in large corporations which have internal firewalls. For example, I have a client which is the merger of two companies, both with their own IT departments and each had their own set of RFC1918 addresses behind a firewall. The effort of re-numbering was too high, so there are two LANS, each behind a portal. No true host-to-host connectivity. But since its all client-server, it doens't matter. Its a nightmare for the network people with the 'redirection' for the servers, though.

-- AntonAylward - 07 May 2003

It occurs to me that a re-write proxy on the firewall could map things

• Initial contact to: http://antonhome.dyndns.org:8080/twiki/bin/view/Main/WebHome
• Returned pages has links like http://antonhome.dyndns.org:8080/http/twikiserver.antonlan.home/twiki/bin/view/Main/WebPreferences

And of course the firewall's proxy redirects that.

But while I see examples of this - not least of all from google - I don't know how to set it up.

-- AntonAylward - 20 May 2003

You might well be able to use Apache for this on the firewall, as it has built-in proxying (Google:Apache+ProxyPass) - as long as it's only listening to the internal LAN side, it should be quite secure, though a dedicated proxy tool might be more suitable for a firewall.

-- RichardDonkin - 20 May 2003

I found this: http://fr.linuxfocus.org/English/March2000/article147.shtml
Still digesting it

The model I initially described was for a firewall that was performing NAT.

-- AntonAylward - 25 May 2003