1

This HAS to be something that can be done. I've searched and found many answers that claim to do what I want, but I can't seem to put it together. So...

I am running a Linux virtual machine under Mountain Lion. The VM runs Apache. I need to redirect all traffic that arrives on the host's port 80 to the guest's port 80. I can reach the VM's web site from the host using: http://192.168.100.2/

I can also reach the default Mountain Lion Apache server from other machines on the local network using: http://10.0.42.22/

(Proving that port 80 is open on the host. And yes, I have tried shutting off the Mac OS installation of Apache to no avail)

I need for other machines on the network to be able to reach the server that is running under the VM by the latter address (http://10.0.42.22/).

I have tried ipfw from the host:

ipfw add 100 forward 192.168.100.2,80 ip from any to any 80 in

After I do that, machines on the local network timeout trying to reach http://10.0.42.22/ instead of reaching the Mac OS "It Works!" screen, which tells me that "something" has happened, but unfortunately, that something isn't that forwarding to the guest is working.

I also tried adding to /etc/pf.conf:

rdr on en1 inet proto tcp from any to any port 80 -> 192.168.100.2 port 80

Followed by:

pfctl -f /etc/pf.conf

Which results in this output:

No ALTQ support in kernel ALTQ related functions disabled

Which is the same thing I get when reloading pfctl with the default configuration. This has no affect (machines on the local network receive the Mac OS Apache default "It Works!" screen). I have also tried using both of the above together, with the results being the same as using only the ipfw trick.

I have read about and tried many combinations of ipfw and pfctl, but none got any different results or seem more correct than what I mention above.

I've done this exact thing for nearly two decades with BSD and various flavors of Linux as the host, but I just can't seem to get it to work with a Mac OS host. I'm hoping that I overlooked something stupid and/or simple and that somebody out there can point out what it is.

Chris Ostmo
  • 113
  • 1
  • 8

2 Answers2

2

I'm coming a little late to answer your question. Your ipfw solution should work, but not as you wrote the rule and, as you don't give a lot information about your configuration, I suppose that you missed a few things :

  • did you set scopedroute to 0 (using sysctl)
  • did you set forwarding to 1 (using sysctl)
  • did you activate the firewall
  • do you nat between the two nets
  • you should forward only packets coming from your local net but the IP of the destination
Olivier
  • 21
  • 2
  • No, yes, yes, yes and done (respectively). Thanks for the input. I've got a method that works for me for the time-being, but it's possible that the `scopedroute` setting was the problem. The Apache reverse proxy solution is much simpler than using ipfw, although, admittedly, I tend to prefer to use technologies for their intended purpose (ipfw for port forwarding and a web server to serve web pages, in this case) instead of relying on favorable side-effects. I'd +1 your answer, but my serverfault reputation doesn't allow for it. – Chris Ostmo Feb 26 '13 at 19:12
  • To add to these really good points, I noticed that ipfw forwarding just plain stops working while PF is on. So also make sure PF is disabled with `sudo pfctl -d`, and that you're not running Mac's ApplicationFirewall / Internet Sharing / AirDrop as they use (and automatically enable) PF. – Dan Apr 20 '13 at 15:17
1

Have you tried shutting down the Mountain Lion Apache instance and setting up an ssh tunnel e.g. 

sudo bash
nohup ssh -L 80:192.168.100.2:80 -N -i ~someUser/.ssh/id_dsa someUser@192.168.100.2 &

Or, alternitively using the Mountain Lion Apache instance to reverse proxy requests to the VM e.g.

ProxyRequests Off
ProxyPass        /  http://192.168.100.2/
ProxyPassReverse /  http://192.168.100.2/
<Proxy *>
  Order Deny,Allow
  Allow from all
</Proxy>

Stick the above in your: /private/etc/apache2/httpd.conf and restart Apache.

arober11
  • 426
  • 3
  • 7
  • Option 1 fails with this message: `Pseudo-terminal will not be allocated because stdin is not a terminal.` I'm not a fan of ssh tunneling for things not ssh, so I don't want to troubleshoot that further. Option 2 produced the exact behavior I was hoping to see, so thank you! In the hours I spent wading through the posts of others with this problem and people giving them incorrect advice, this is the first time I've seen anyone suggest using Apache's reverse proxy. It's so obvious now that you mention it. :-) Now let's try to convince Apple to stop intentionally breaking BSD utilities. – Chris Ostmo Dec 27 '12 at 19:25
  • Whoops, the original all in one sudo call was missing a couple of quotes, have edited the line and split it into two. – arober11 Dec 29 '12 at 12:02