1

I've never run across this before...

I've been messing with different apache servers at home while at work. Before I got the proxypass working, I needed to be able to hit server number two from outside the local network.

I did it by setting up port forwarding on my router (linksys running dd-wrt). It went something like my.pub.ip.add:28000 forwarded to server number two's :80. Worked fine. That's what I needed.

So, I finally set up the proxypass on server number one to forward requests from my www.domain.com to server number two, meaning I'd no longer require the port forwarding to hit server two directly.

Now, when I go to www.domain.com from a browser, it times out, but it does so with my server two's local IP in the address bar, appended with the original (and seemingly totally unrelated) public port I'd set up earlier.

So, typing www.domain.com, times out with 192.168.x.x:28000 in the address bar.

I can accept that my apache config is not yet correct, but even when trying to hit server two from inside the LAN, just typing 192.168.x.x, it still appends that port. I can try something like 192.168.x.x:80 and it still replaces it with :28000.

  • I've turned off the port forwarding I'd used earlier. I did that immediately because the random port I'd used to get into my LAN was sitting right out there!!

  • I ssh'd into the dd-wrt router and flushed the dnsmasq, thinking that may have hung on to something, per a suggestion on a google search.

  • And it otherwise seems to be a difficult thing to google for.

To be honest, I'm not really sure where to be focusing my attention. The router, because it's the gateway and local dns? The apache install on server 2? The Ubuntu OS that is server 2?

The question, in the end, is why is the port that I made up to direct public traffic to my server two being appended to local and external requests to server two even after removing that port forwarding rule?


EDIT:

Starting to narrow it down. It seems to be an issue with Wordpress. Basically, I did the Wordpress install via ssh, but then the initial configuration and testing with a browser (hence the port forwarding).

It would seem that the Wordpress install is stubbornly hanging onto the method of access from before. Any recommendations on where to focus in the Wordpress install?

2 Answers 2

0

I'd start by grepping my Apache config files (on both servers) for 28000.

I'm guessing that at some point you had told Apache about port 28000 because you needed Apache redirects on Server 2 to redirect you to a correct URL for Server 2, and a correct URL for Server 2 (when you're connecting from outside) has to have :28000 in it.

For example, back when you needed that port mapping to hit Server 2, if you had gone to http://www.domain.com:28000 (without the trailing "/") and it redirected you to add the trailing "/", if it didn't know that port 28000 was in play, it would have redirected you to "http://www.domain.com/" (i.e. the front page of Server 1) instead of "http://www.domain.com:28000/" (i.e. the front page of Server 2).

So you probably told Apache about port 28000 to get those redirects working correctly, but now you've forgotten you did it.

2
  • But that's the thing, apache never had anything to do with 28000. It was a default install listening on 80. No virtual hosts or anything on #2. I will check for any reference to the port within apache. Thanks for the suggestion :)
    – JoshP
    Commented Aug 3, 2012 at 1:28
  • Just as a test, I switched the static IP on server2 and tried to hit it from within the LAN. Still appended the port. Does that sound telling at all?
    – JoshP
    Commented Aug 3, 2012 at 2:34
0

Ok, got it solved.

Wordpress does indeed make note of absolute URLs in the database. When I was setting up the site with the http:my.pub.ip.add:28000/wp-admin (port forwarded through router) address, Wordpress actually made a note of that address. That's where it thought it lived.

In the end, I used the "Relocate Method" referenced on this page of the Wordpress codex.

Quoting:

Note: When the RELOCATE flag is set to true, the Site URL will be automatically updated to whatever path you are using to access the login screen. This will get the admin section up and running on the new URL, but it will not correct any other part of the setup. Those you will still need to alter manually.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .