Question

I set TWiki without root acces on intranet server. I have to set in .htaccess a redirect, because without this twiki don't work. In intranet works twiki very well, but I have a problem in internet. All links with host adress are set to numerous value and not to host name. So http://web.esg.de/projekte/daisy/twiki/ is set to http://192.168.101.74/projekte/daisy/twiki/ and this don't works.

Is it a config problem with apache ?

Have I need a alias for twiki ?

Reimund

• TWiki version: 01 Dec 2001
• Perl version: 5.6.1
• Web server & version: Apache/1.3.23
• Server OS: Linux Suse
• Web browser & version: all
• Client OS: W2K

-- ReimundGoerlich - 16 Dec 2002

Answer

An IP address like 192.168.101.74 (and in fact, anything that starts with 192 (and some other addresses, including some that start with 10.something)) is a private address that works only on an intranet and not on the Internet.

I won't (and probably can't) explain why this is, but it is true, and to solve the problem you need to arrange to get something more than you apparently have, like a registered domain name, or perhaps the services provided by someone like dyndns.org. Maybe you want to get web hosting services from a web hosting services provider. See Codev.TWikiOnWebHostingSites for some free or inexpensive web hosting providers that have been successfully used for TWiki. See also Codev.HostedSiteInstallationGuide for information on how to install TWiki at such a site.

Someone may be able to give you more information, but the problem you are having is not a TWiki problem but an Internet hosting problem. (Once you solve it, you may have some TWiki tweaking to do, but until you solve it, no amount of TWiki tweaking will solve your problem.)

-- RandyKramer - 17 Dec 2002

It works with some settings in TWikiPreferences.

• Set HTTP_HOST = web.esg.de
• Set PUBURL = http://web.esg.de/projekte/daisy/twiki/pub
• Set SCRIPTURL = http://web.esg.de/projekte/daisy/twiki/bin
• Set ATTACHURL = http://web.esg.de/projekte/daisy/twiki/pub/%WEB%/%TOPIC%

-- ReimundGoerlich - 18 Dec 2002

Sorry, I guess my answer was off the mark (i.e., wrong) and it sounds like you managed to solve your problem. So I'm switching the SupportStatus of this question to AnsweredQuestions.

If I misunderstand (again) and you still have a question or problem, change the SupportStatus back to AskedQuestions and provide a little more information specifying your question. (I'll let somebody else try to answer it next time. )

(Just musing -- I guess my answer wasn't totally wrong in that you do need a publicly accessible IP address, but I didn't realize that web.esg.de is apparently registered and has such an IP address.)

-- RandyKramer - 18 Dec 2002

Actually that server does have a public IP address (it must have to be on the Internet):

$ ping web.esg.de
Pinging web.esg-gmbh.de [194.15.135.70] with 32 bytes of data:

Probably the server is accessible via the intranet and the Internet, with the former having the 192.168.x.x address.

-- RichardDonkin - 19 Dec 2002

Let me stick my oar in here. One of the things on my 'to do' list is this point, but the topic title does not describe what the problem is. It is the mapping of a NAT'd address through a firewall. Perhaps we need the topic InternetAcccessofaNATedTwiki or something like that.

Many SOHOs and home users on DSL have set up an internal "household" net that "hides" behind a single IP address by using a Network Address Translation mechanism in a LinkSys cable router or a Linux firewall running on an old box. THis started as a way to deal with the consupmtion of the address space of IPv4 but has proven very useful for other rasons. It is so widespread that there ought to be a TWiki topic that deals with configuring for it.

Normally NATs are configured to allow outgoing requests and block incming requests (but not replies). Unless you are running a server on your firewall - which is astoundingly bad practice and a serious risk and impossible with some hardware - the inside net is blocked. Please note this in't like a conventional "by the book" firewall where the DMZ or itnernal network does have a public network address and is therefore routable.

Yes, one can create a "hole" in the NAT's firewall. What one does is redirect rather than just open a port. The translation has to be done both ways, and the address the server thinks its using is the private net not the one the client is using, as ReimundGoerlich pointed out.

RichardDonkin was not correct when he said the server had an internet addess, or at least pinging web.esg.de doesn't prove that. The address [194.15.135.70] is more likely to be that of the firewall or NAT translator. Caveat: It is possible that its a box with [194.15.135.70] on one side running a server and [192.168.101.74] on the other, but I doubt it. That would be very insecure. The use of the .101. subnet makes th suspect that esg.de has a number of subnets behind the NAT.

For many people there are two other problems:

1. Your DSL/cable ISP may have a clause in your EULA that prohibits you running a server. In all probability they also scan you occasionally to make sure. There are ways around that but they may also lock out legitimate users.
2. Again for users of DSL/cable the domain address corresponding to your IP address is determined by your ISP. They are not in the same situation as web.esg.de. Yes, you can use a service such as that provided by http://www.dyndns.org but if the client server wants to verify that the forward mapping and the backward mapping match you have a problem. Some client software does this to ensure that site is not being spoofed. This has ramifications if you try using SSL.

Yes, the question as asked ReimundGoerlich asked is closed, his problem solved, but that's not a generic. We do need a How-To in the installation guide to deal with the situation of making TWikis on servers on NAT'd networks availabe outside of that network. But as Randy says, this is really a network problem. It will need the cooperation of the Twiki but its a common network problem. However that doens't mean it shouldn't be addressed in installation guide.

-- AntonAylward - 20 Dec 2002

By setting the TWikiPreferences as shown above, all TWiki links are using the "Internet" interface (web.esg.de, 194.15.135.70), and never the "Intranet" interface (192.168.101.74). If this is undesirable, an Apache virtual host configuration, with an internal and an external virtual host could be used. The "ServerName" directive will then assign a correct hostname to each interface and to all self referencing links depending on how you start TWiki initially (web.esg.de/twiki_path or 192.168.101.74/twiki_path).

-- FrankThommen - 07 Jan 2003