Remote PHP inside a masquerading firewall

Anon

I wonder if anyone here can help with a newbie problem.

I have a Linux machine which is my external webserver (Apache), running PHP3.
This machine also uses ipchains to masquerade my internal network, which contains an intranet server, also with PHP3.

My problem is that I want [some of] the PHP scripts on the external webserver
to execute more PHP scripts on my intranet server. These internal scripts call
Informix 4GL programs via system(), and the output is transferred back to the
external webserver for display. Works nicely from inside our corporate LAN, but
from outside, it's a no-go. The idea here is that our developers need not have access to the external web server/firewall, and that the firewall machine has only trivial PHP scripts that call the 'real' scripts from an internal machine.

Everthing works fine from inside the firewall, where all machines are DNS-able,
but from outside, nothing works as the client browsers cannot resolve DNS or
access an internal address. I was hoping to get Apache to do the DNS resolution
itself, as it is on the firewall and can access both internal and external
machines. No such luck, I can't get away from the client browser wanting to
resolve the name/ip itself. Anyone know of another way to call a remote PHP
script that might be inside a firewall, and on a machine that has a masqueraded
address?

TIA

Bryan Tonnet
bryan@printman.net

Anon

You can probably solve this by making static translation rules on your firewall.
ie: tell the firewall to allways translate a surtain external IP# to a set internal IP# or the other way around.

This way, a server on the inside of your firewall can be reached using an IP number on the outside of your firewall.

Get the picture?

Anon

Hi,

I would say, make a file that reads out the output of the scripts from the internal server...

e.g. server1(external) | server2(internal)
asksomething.php | replyto.php
|

asksomething.php:
$fp = fopen("http://server2/replyto.php");
while (!(feof($fd))) $buffer += fgets($fp,4096);

replyto.php:
echo "everything you need!";

Hope this helps...

Grtz,
Remon

[deleted]

Masqurading (or address translation) means that the network on the inside of the firewall uses IP numbers that don't exist on the outside. Thus you can't access the internal server from the outside; it's IP number is invalid!

Anon

Duh,

I know that, but now this:
APACHE+PHP run on the external server which knows the internal IPs!
I got the same situation here!
See this

INTERNET <---> MASQ+WEB+PHP <---> Internal net

0.0.0.0 <---> 212.33.33.33 (external ip)
(internal ip)192.168.100.1 ---> Internal net(also the internal PHP server)

this way, your socalled external webserver can connect to your internal web/PHP-server

Here goes the way of packets:
Pagerequest -> External server
External Server -> asks internal server for data/output
Internal server replies -> external server
External server -> Pagereply

And done is everything, if it doesn't work you can shoot me, it runs fine here..

Anon

I know that, but now this:
APACHE+PHP run on the external server which knows the internal IPs!
I got the same situation here!
See this

INTERNET <---> MASQ+WEB+PHP <---> Internal net

0.0.0.0 <---> 212.33.33.33 (external ip)
(internal ip)192.168.100.1 ---> Internal net(also the internal PHP server)

this way, your socalled external webserver can connect to your internal >web/PHP-server

Thanks for this, but this is pretty much what I've attempted without success. The problem is that when I use a construct such as you mention above with fopen or whatever, it's the external client browser that ultimately tries to do a DNS lookup and connect, not the Apache server. If there was some mechanism to fopen("internalserver.domain.com"), with the DNS lookup being done by the server where the calling PHP script resides, then the problem would be solved easily. Unfortunately, I haven't found that yet.

Here goes the way of packets:
Pagerequest -> External server
External Server -> asks internal server for data/output

This is where I can't get it to fly. The remote browser tries to do the connection, and can't resolve internalserver.domain.com, and even if it could it couldn't reach 192.168.1.2.

Internal server replies -> external server
External server -> Pagereply

And done is everything, if it doesn't work you can shoot me, it runs fine here..

I'd be very keen to get more info from you on this. Obviously you're doing something I'm not, 'cause as I said, I'm still drawing a blank. So my PHP scripts sit on my firewall, and I have an admnistrative headache uploading twice a day, as the developers change things and enhance things. If the firewall could have a generic calling PHP script and the 'real' workhorses lived on the internal production machine, things would be much more streamlined.

Anxiously awaiting.... 🙂

Bryan Tonnet

[deleted]

As I said in my very first reply;

Only the firewall knows about the 192.x.x.x numbers on the inside.
The internet doesn't recognise those numbers, so they can't ever be reached from the internet (this is in fact one of the resons why MASQ was invented)
If you want to access the inside from the outside, you need to make the inside available on the outside.
That means assigning a new, real IP number to the firewall. Then you create a special translation rule that allways translates the new IP on the outside to the fake IP on the inside and vice-versa.
Now you can access the internal server through the new external IP.

remon

Now, i've tested it, and it works:

this file is on the firewall(eg external webserver), called test.php:

$fd = fopen("http://192.168.100.5/internalserverfile.php","r");
$buffer = fgets($fd, 4096);
while (!(feof($fd)))
{
$buffer = fgets($fd, 4096);
echo $buffer;
}
fclose ($fd);

and opens a file on the internal server and reads it, this works just fine!

Possible your DNS on the external server isn't working correct? I think this is your problem here... A script running on your external server doesn't ask your clients browser to resolve the file opened above in the script.

Hoping to here what you've got to say ;-))

Remon

[deleted]

Hello Remon, how many times do I have to say this to make it clear? 192.168.x.x numbers are not used on the internet! ergo, you can't find a route to it ergo you can't use them on the internet!
You can't connect from the outside to the inside without changing the firewall. That is what a masquerading firewall is for.

Anon

Possible your DNS on the external server isn't working correct? I think this is >your problem here... A script running on your external server doesn't ask your >clients browser to resolve the file opened above in the script.

I guess anything's possible 🙂 When I was trying this a few months back, I found that if I was on an internal browser (one that could resolve 192.168.x.y as well as 'real' addresses), then running a remote internal script from the firewall worked fine. If I, as you have, ran the first script on the firewall itself, then also everything worked fine. However, as soon as I tried it from an external browser, then I got "could not resolve address blah blah" messages on the client when the first script tried to fopen the internal URL. This seemed to indicate to me that the client was trying to resolve the address, not the server. I have been wrong before today however.

Just tried it again with the same results. So long as the client browser can resolve both domains, everythings fine. As soon as the client is in the 'real' world, then no dice. Same thing happens if I try a redirect through Apache or if I try and get Apache to proxy it through.

I might try the translation idea that ?Vincent? had.

Bryan Tonnet

[deleted]

Finally... I was beginning to wonder if I was invisible... 🙂

remon

NOW DO I HAVE TO TELL YOU BOTH

IT WORKS FINE!
1000% SURE!

Vincent : You don't know what you're talking about, off course 192.168.x.x isn't reachable from outside. But the script is running on the firewall, which HAS access to the internalnet(192.168.x.x). So the PHP server on the firewall know 192.168.x.x and uses it's DNS to resolve it.

Bryan : Try to set your DNS correct on your external PHP server.

try things on the firewall like:
nslookup

server 192.168.100.1 (firewall ip)
192.168.100.5 (internal server)
found? OK than things are ok.

and try looking in /etc/resolv.conf:
nameserver 127.0.0.1
the above string must be the first or second line in this file.

eventually check /etc/nsswitch.conf:
hosts: files dns nis

if you set it like above, you can use /etc/hosts to enter names for the internal ip's eg.:
192.168.100.1 externalserver
192.168.100.5 internalserver

this way you can use : ping internalserver on the firewall...

I don't know anything more to say...

I've tested it, if not sure:
http://www.vdwerff.nl/~remon/test.php
this is the file pasted in previous post.
IT OPENS A FILE FROM MY INTERNAL SERVER 192.168.x.x using fopen();
Tell me if it isn't working, I know it'll work. (One picture isn't working because it's one the other server.)

Greetz,
Remon
(Let me know!)

[deleted]

Oh I'm sorry, I missed the part where you said it was running on the firewall.

Then again, running a webserver on a firewall is dumb, and putting PHP on it is even dumber.
Especially if you can solve the whole issue by using one of the firewall's most basic functions.

But then again, I don't know what I'm talking about....

remon

Firewall+webserver+php is superb...
firewall, webserver behind it is absurd, then when people get in to your webserver they are in your internal net to..

Grtz,
R

[deleted]

firewall+apache+php is absurd.
If users get into the apache, they are in your firewall.

If you set up a static translation to allow the external webserver to talk to the internal webserver you're safer.
This is still not good, but better than running a webserver on a firewall, especailly with PHP on it. remember the fsockopen function?