LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Networking (https://www.linuxquestions.org/questions/linux-networking-3/)
-   -   Easiest way to redirect external web traffic to VMWare web host on same machine? (https://www.linuxquestions.org/questions/linux-networking-3/easiest-way-to-redirect-external-web-traffic-to-vmware-web-host-on-same-machine-739904/)

mattp52 07-14-2009 12:41 AM

Easiest way to redirect external web traffic to VMWare web host on same machine?
 
Hi,

Have done a bit of Googling around this but got totally swamped so will try here. Basically we are running a CentOS server which hosts a number of virtual hosts under Apache. Recently I needed to set up a development environment for another site using Ubuntu and have this running and accessible on the LAN from a VMWare image. I'm using bridged networking so the VMWare machine has its own IP on the LAN subnet.

I've set up a DNS to point to the external IP of the physical host but can't figure out how to route traffic requested on this domain to the VMWare host. I've basically tried two approaches (configuring a proxy web server and reverse proxy in an httpd.conf file and mucking around with iptables forwarding rules but without success.

Ideally I'd like somesite.somewhere.com to point to the VMWare IP but I could live with a custom port on the end if thats whats required.

To throw further complication into the mix I need reliable communication between the VMWare machine and external mail relay servers in order to debug any issues with mail bouncebacks, embargos etc.

Any idea what's the easiest way to accomplish this?

unSpawn 07-14-2009 06:56 PM

"Easiest" usually means something along the lines of "don't bother me (with security and all that bullsh*t) and make it work now regardless of the consequences". I hope that's not true in your case. I also hope the phrase "development environment" means that net-facing access to this VM guest is locked down to port TCP/80 only, that the VM guest is properly hardenend and doesn't give access to accounts with default or weak passwords like "test" or "blah"... That said, it is a best practice to separate LAN machines from net-facing ones. The latter belong in a DMZ for obvious reasons. In any case I see is no reason (but then again I'm no LARTC guru) why a GNU/Linux Vmware host couldn't perform the role of DMZ router forwarding traffic to other DMZ machines. And the fact they're VM guests doesn't matter since you use bridging. However you should start by posting verbose information like the steps you took to do forwarding (adding "-j LOG" rules helps troubleshooting) because saying "but without success" isn't enough nfo to go on.

mattp52 07-14-2009 10:00 PM

Quote:

Originally Posted by unSpawn (Post 3607819)
"Easiest" usually means something along the lines of "don't bother me (with security and all that bullsh*t) and make it work now regardless of the consequences". I hope that's not true in your case.

Yes... easiest wasn't perhaps the best choice of words - "simplest, robust and secure" might be better.

Here's the basic network topology.

Code:

                                eth1        eth0
    [VMWareHost] --------------------[ Host/Firewall ]-------------- Internet
  192.168.2.49              192.168.2.6  192.168.2.5    public-ip        0.0.0.0/0


I'm wanting requests to public-ip:8081 to be forwarded to VMWareHost:80 and for responses from VMWareHost to also be mapped correctly. Here's an extract of an otherwise working iptables configuration script. The script flushes iptables, writes these rules, saves and lists them.

Code:

#
# Set default policies for INPUT, FORWARD and OUTPUT chains

 $IPTABLES -P INPUT DROP
 
 $IPTABLES -P FORWARD DROP
 $IPTABLES -P OUTPUT ACCEPT


$IPTABLES -A FORWARD  -p tcp --dport 8081 -d 192.168.2.49 -j ACCEPT

#
# ALLOW internal LAN nodes to communicate with external networks...
#
$IPTABLES  -o eth1 -A POSTROUTING  -j MASQUERADE

#Also tried these alternatives without success...
  #$IPTABLES -t nat -A POSTROUTING -p tcp --dport 8081 -j SNAT --to-source  192.168.2.6
  #$IPTABLES -t nat -A POSTROUTING -o eth0 -j MASQUERADE


#
# Route external traffic on port 8081
#
$IPTABLES  -A PREROUTING -i eth1 -p tcp --dport 8081 -j DNAT --to-destination 192.168.2.49:80

#Also tried:
  #$IPTABLES -t nat -A PREROUTING -p tcp --dport 8081  -j DNAT --to 192.168.2.49
  #$IPTABLES -t nat -A PREROUTING -p tcp --dport 8081 -j DNAT --to-destination 192.168.2.49:80
  #$IPTABLES -t nat -A PREROUTING -i eth0 -p tcp --dport 88 -j DNAT --to 192.168.2.49:80

...
After this have pre-existing INPUT OUTPUT filters locking down other services ports (nothing else added for forwarding).

Saving this configuration, all attempts to hit the VHOST via the host on port 8081 time out.

I'm on RHEL (CentOS5) and have confirmed that IP forwarding is enabled in '/etc/sysctl.conf' -->
Code:

net.ipv4.ip_forward = 1

Hope this is more useful in troubleshooting.

r0b0 07-16-2009 09:26 AM

We have a similar setup - forwarding web traffic from our GW to a dev box in our internal network.

What we do is that we have a sub-domain in DNS (e.g. dev.site.com) to point to our GW public IP address (e.g. 1.2.3.4) and a name-based virtualhost in apache for this sub-domain proxying traffic to the internal address (DNS or IP) of the dev box (e.g. 192.168.0.10):

Code:

<VirtualHost 1.2.3.4>
        ServerName dev.site.com

        RewriteEngine On
#      RewriteLogLevel 5
#      RewriteLog /tmp/rewrite.log

        RewriteRule ^(.*) http://192.168.0.10$1 [P,L]
</VirtualHost>

R.

mattp52 07-16-2009 02:47 PM

Quote:

Originally Posted by r0b0 (Post 3609601)
We have a similar setup - forwarding web traffic from our GW to a dev box in our internal network.
...
R.

Interesting... so you didn't need to alter your firewall at all to support this set-up (other than ensure the system allows IP forwarding presumably). I did go part way down the track of trying to solve the problem using mod_proxy directives with Apache but couldn't get that working either.

I'll give it a go. Thanks.


All times are GMT -5. The time now is 09:49 AM.