Skip to content
This repository has been archived by the owner. It is now read-only.

Yosemite Support #452

Closed
mhodgson opened this issue Jun 3, 2014 · 225 comments
Closed

Yosemite Support #452

mhodgson opened this issue Jun 3, 2014 · 225 comments

Comments

@mhodgson
Copy link

@mhodgson mhodgson commented Jun 3, 2014

Unfortunately, Yosemite breaks pow because ipfw has been completely removed from the OS. I was able to get pow working again using PF, which is the new recommended way to do port forwarding in OS X. Here's what I did to get it working:

First, add an anchor file to contain the pow port forwarding rule. Place the following code in /etc/pf.anchors/com.pow:

rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 20559

NOTE: The trailing line break is required. Otherwise pf will say you have a syntax error.

Next, add two lines to /etc/pf.conf to load your new rule. It is important where these lines go. Add this line right after rdr-anchor "com.apple/*":

rdr-anchor "pow"

Add this line directly after load anchor "com.apple" from "/etc/pf.anchors/com.apple":

load anchor "pow" from "/etc/pf.anchors/com.pow"

Again, make sure to maintain the final line break.

Next, reload the rules into pf by running sudo pfctl -f /etc/pf.conf

Finally, enable pf by running sudo pfctl -e

Interested to hear how other people fare with this. I would provide a pull request but I'm not familiar with the internals of pow or the way this should be implemented.

@dudeman
Copy link

@dudeman dudeman commented Jun 3, 2014

Thanks for this! Helped get Pow mostly working for me. Seems that there's still issues if you're using a custom TLD with pow (something other than .dev or .test)

@Guoxweii
Copy link

@Guoxweii Guoxweii commented Jun 4, 2014

thanks for this! But how can this support visit by other ip, eg: http://192.168.37.222

@craigtsmith
Copy link

@craigtsmith craigtsmith commented Jun 4, 2014

+1 this works like a charm, thanks so much.

@mhodgson
Copy link
Author

@mhodgson mhodgson commented Jun 4, 2014

@LittleLuRen shoot! You can update the rule like so:

rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 20559

That should bring the rule up to parity with the current ipfw rule.

@mhodgson
Copy link
Author

@mhodgson mhodgson commented Jun 4, 2014

@LittleLuRen I verified that the updated rule works. I also updated the issue description to recommend the new rule.

@Guoxweii
Copy link

@Guoxweii Guoxweii commented Jun 4, 2014

thanks for your help! but l still failed 。。。。

my ipconfig
123

@adooylabs
Copy link

@adooylabs adooylabs commented Jun 4, 2014

👍 Thanks @mhodgson and for the update @LittleLuRen

@aemadrid
Copy link

@aemadrid aemadrid commented Jun 4, 2014

Very cool, thx. Worked for me just fine.

@eploko
Copy link

@eploko eploko commented Jun 4, 2014

Thanks a ton guys for solving this. Removal of ipfw from Yosemite was kind of unexpected. The steps outlined work like a charm. :)

@ashchan
Copy link

@ashchan ashchan commented Jun 4, 2014

Wow works like a charm! Many thanks 👍 !

@afraser
Copy link

@afraser afraser commented Jun 5, 2014

Nice! Props @mhodgson.

@makzan
Copy link

@makzan makzan commented Jun 5, 2014

Thanks @mhodgson. It works.

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 5, 2014

This is great, thanks!

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 5, 2014

Is pf available on older systems? Or is it something new in 10.10?
Found the answer myself:

In OS X Lion and OS X Mountain Lion, though, ipfw was deprecated in favor of pf, the powerful packet filter that I believe originated on OpenBSD. (OS X’s version of pf is ported from FreeBSD.) In this article, I’m going to show you how to use pf on OS X.

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 5, 2014

Altering system configuration from a script (the installer) could be dangerous, so when we'd like to integrate this in the installer, it would be nice to know if it's possible to load multiple configs into PF.

For example
/etc/pow.pf.conf:

rdr-anchor "pow"
load anchor "pow" from "/etc/pf.anchors/cx.pow"

/etc/pf.anchors/cx.pow:

rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 20559

And an extra launchagent, cx.pow.pfctl.plist:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Disabled</key>
    <false/>
    <key>Label</key>
    <string>cx.pow.pfctl</string>
    <key>WorkingDirectory</key>
    <string>/var/run</string>
    <key>Program</key>
    <string>/sbin/pfctl</string>
    <key>ProgramArguments</key>
    <array>
        <string>pfctl</string>
        <string>-f</string>
        <string>/etc/pow.pf.conf</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
</dict>
</plist>
@mhodgson
Copy link
Author

@mhodgson mhodgson commented Jun 5, 2014

@koenpunt To answer you previous question, ipfw has been deprecated in favor of pf since 10.7 (Lion). I'm not sure what pow attempts to support, but we may be able to just completely switch to pf. You're solution looks ok, interested to know if it works. Looks like Apple is using pf for a lot of system services so I'm worried it will introduce bugs in other areas, but who knows...

@adooylabs
Copy link

@adooylabs adooylabs commented Jun 9, 2014

Anybody having issues when restarting mac /etc/pf.conf won't give loaded so I need to do "sudo pfctl -f /etc/pf.conf" and "sudo pfctl -e" again?

Should we manually add a launch agent?

@eploko
Copy link

@eploko eploko commented Jun 9, 2014

@adooylabs yep, same thing happens here. sudo pfctl -e seems to be needed after each reboot. It seems you don't need the pfctl -f part each time, though.

@mhodgson
Copy link
Author

@mhodgson mhodgson commented Jun 9, 2014

@eploko @adooylabs from the default pf.conf file:

#
# Default PF configuration file.
#
# This file contains the main ruleset, which gets automatically loaded
# at startup.  PF will not be automatically enabled, however.  Instead,
# each component which utilizes PF is responsible for enabling and disabling
# PF via -E and -X as documented in pfctl(8).  That will ensure that PF
# is disabled only when the last enable reference is released.
#
# Care must be taken to ensure that the main ruleset does not get flushed,
# as the nested anchors rely on the anchor point defined here. In addition,
# to the anchors loaded by this file, some system services would dynamically
# insert anchors into the main ruleset. These anchors will be added only when
# the system service is used and would removed on termination of the service.
#
# See pf.conf(5) for syntax.
#

So it appears that when/if this is incorporated into POW, we will need to make sure to enable pf when POW boots up.

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 10, 2014

So maybe pfctl should be called from the pow daemon itself?

@mhodgson
Copy link
Author

@mhodgson mhodgson commented Jun 10, 2014

@koenpunt I think that is exactly what needs to happen. It also looks like it should make sure to disable it (-X) when the daemon exists.

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 10, 2014

Hm ok, I tried to dynamically add the rule to an anchor but couldn't get it to work.

For example, adding it to the existing com.apple/* anchor:

echo "rdr pass on lo0 inet proto tcp from any to any port http -> 127.0.0.1 port 20559" | sudo pfctl -a 'com.apple/*' -f - -E

Got any suggestions for this?

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 10, 2014

Oh never mind, got it fixed in #453 by adding the rule to com.apple/250.ApplicationFirewall.

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jun 10, 2014

Sidenote, calling pfctl from the daemon is not possible because it runs as the user and pf requires root privileges.

@piersadrian
Copy link

@piersadrian piersadrian commented Jun 12, 2014

Thanks for this @mhodgson! 👍

@jimbocortes
Copy link

@jimbocortes jimbocortes commented Jun 17, 2014

thanks @mhodgson !

@brewster1134
Copy link

@brewster1134 brewster1134 commented Aug 29, 2015

DNS reset did not work for me. also played around with oh-my-zsh update issues... still ERR_CONNECTION_REFUSED

@nodesocket
Copy link

@nodesocket nodesocket commented Oct 20, 2015

Tested in El Capitan and seems to work. Here is a little copy and paste guide which should work. It does the following:

Port 8888 => 80
Port 4444 => 443

sudo tee /etc/pf.anchors/com.pow > /dev/null <<'EOF'
rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 8888
rdr pass on lo0 inet proto tcp from any to any port 443 -> 127.0.0.1 port 4444

EOF

Then:

sudo tee /etc/pf.conf > /dev/null <<'EOF'
#
# com.apple anchor point
#
scrub-anchor "com.apple/*"
nat-anchor "com.apple/*"
rdr-anchor "com.apple/*"
rdr-anchor "pow"
dummynet-anchor "com.apple/*"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"
load anchor "pow" from "/etc/pf.anchors/com.pow"

EOF

Finally:

sudo pfctl -f /etc/pf.conf
sudo pfctl -e
@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Oct 24, 2015

@nodesocket The default setup should work fine on El Capitan. Also, you refer to non-standard ports in your "copy and paste guide".

@krishnarohitreddy
Copy link

@krishnarohitreddy krishnarohitreddy commented Nov 19, 2015

thank you this worked for me :-)

@Wissam-Halimi
Copy link

@Wissam-Halimi Wissam-Halimi commented Nov 25, 2015

this is super cool! easiest copy paste I've ever done! Thanks!!!

@davidhq
Copy link

@davidhq davidhq commented Jan 11, 2016

Thank you so much...

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 27, 2016

ykhddeiMac:etc ykhd$ sudo pfctl -f /etc/pf.conf
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.

No ALTQ support in kernel
ALTQ related functions disabled
ykhddeiMac:etc ykhd$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pfctl: pf already enabled

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 27, 2016

rdr pass on lo0 inet proto tcp from any to any port 10080 -> 192.168.99.100 port 10080

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 27, 2016

ykhddeiMac:etc ykhd$ sudo pfctl -f /etc/pf.conf
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.

No ALTQ support in kernel
ALTQ related functions disabled
ykhddeiMac:etc ykhd$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pfctl: pf already enabled

this is why? OSX 10.11.3

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 27, 2016

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 27, 2016

scrub-anchor "com.apple/"
nat-anchor "com.apple/
"
rdr-anchor "com.apple/"
rdr-anchor "pow"
dummynet-anchor "com.apple/
"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"
load anchor "pow" from "/etc/pf.anchors/com.pow"

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jan 27, 2016

You shouldnt mess with /etc/pf.conf IMHO

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 28, 2016

@koenpunt What do you mean?

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 28, 2016

add two lines to /etc/pf.conf to load your new rule ,Above wrote

@YiHuaTian
Copy link

@YiHuaTian YiHuaTian commented Jan 28, 2016

@mhodgson

rdr pass on lo0 inet proto tcp from any to any port 10080 -> 192.168.99.100 port 10080

scrub-anchor "com.apple/"
nat-anchor "com.apple/"
rdr-anchor "com.apple/"
rdr-anchor "pow"
dummynet-anchor "com.apple/"
anchor "com.apple/*"
load anchor "com.apple" from "/etc/pf.anchors/com.apple"
load anchor "pow" from "/etc/pf.anchors/com.pow"

ykhddeiMac:etc ykhd$ sudo pfctl -f /etc/pf.conf
pfctl: Use of -f option, could result in flushing of rules
present in the main ruleset added by the system at startup.
See /etc/pf.conf for further details.

No ALTQ support in kernel
ALTQ related functions disabled
ykhddeiMac:etc ykhd$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pfctl: pf already enabled

this is why? OS X 10.11.3 Is there a problem?

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Jan 28, 2016

I mean that it's not necessary, just append to the main rule:

echo "rdr pass proto tcp from any to any port {80,20559} -> 127.0.0.1 port 20559" | pfctl -Ef -

See also #521

@davidmoore-io
Copy link

@davidmoore-io davidmoore-io commented Feb 22, 2016

See also #524 if you're having the same symptoms on 10.11.x and are running an openVPN client.

@wujinhong
Copy link

@wujinhong wujinhong commented Sep 2, 2016

No ALTQ support in kernel
ALTQ related functions disabled
ykhddeiMac:etc ykhd$ sudo pfctl -e
No ALTQ support in kernel
ALTQ related functions disabled
pfctl: pf already enabled
what is wrong? Does someone know the reason? OS X is 10.11.6 (15G31)

@uxp
Copy link

@uxp uxp commented Nov 29, 2016

The No ALTQ support in kernel messages can be ignored.

Basically, ALTQ is "Alternate Queueing", which is used for Quality of Service (QoS). This just enables one to configure queues within PF to prefer certain types of network traffic to have priority over others (e.g. VoIP over Torrents). No one here should be needing this with regards to Pow.

FreeBSD's GENERIC kernel ships without ALTQ support, as does MacOS' XNU Kernel. ALTQ is an optional, but preferred feature when using OpenBSD's PF Firewall. In order to enable ALTQ, one has to recompile the FreeBSD kernel with said support. Since we don't need this optional feature, and because recompiling the XNU kernel and including ALTQ is way beyond the scope of this issue with Pow, we can safely ignore this message.

https://www.freebsd.org/doc/handbook/firewalls-pf.html#idp76909288

@bjensen
Copy link

@bjensen bjensen commented Apr 4, 2018

Is this a closed issue? I still have to do the following after each restart:

sudo pfctl -f /etc/pf.conf; sudo pfctl -e High Sierra. Pow 0.6.0 installed using homebrew...

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Apr 4, 2018

Have a look at puma-dev instead. This is also mentioned in the MANUAL.md

@bjensen
Copy link

@bjensen bjensen commented Apr 7, 2018

@koenpunt puma-dev works with unicorn?

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Apr 7, 2018

@bjensen no, with Puma. But would that be a problem, to use a different server in development? Also; is there a specific reason you're using unicorn?

@bf4
Copy link

@bf4 bf4 commented Apr 7, 2018

@koenpunt
Copy link
Contributor

@koenpunt koenpunt commented Apr 7, 2018

@bf4 true, but that requires you to manually start the server

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

You can’t perform that action at this time.