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

Comments

Projects
None yet
@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

This comment has been minimized.

Show comment
Hide comment
@dudeman

dudeman 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)

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

This comment has been minimized.

Show comment
Hide comment
@Guoxweii

Guoxweii Jun 4, 2014

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

Guoxweii commented Jun 4, 2014

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

@craigtsmith

This comment has been minimized.

Show comment
Hide comment
@craigtsmith

craigtsmith Jun 4, 2014

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

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

@mhodgson

This comment has been minimized.

Show comment
Hide comment
@mhodgson

mhodgson 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 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

This comment has been minimized.

Show comment
Hide comment
@mhodgson

mhodgson Jun 4, 2014

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

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

This comment has been minimized.

Show comment
Hide comment
@Guoxweii

Guoxweii Jun 4, 2014

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

my ipconfig
123

Guoxweii commented Jun 4, 2014

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

my ipconfig
123

@adooylabs

This comment has been minimized.

Show comment
Hide comment
@adooylabs

adooylabs Jun 4, 2014

👍 Thanks @mhodgson and for the update @LittleLuRen

👍 Thanks @mhodgson and for the update @LittleLuRen

@aemadrid

This comment has been minimized.

Show comment
Hide comment
@aemadrid

aemadrid Jun 4, 2014

Very cool, thx. Worked for me just fine.

aemadrid commented Jun 4, 2014

Very cool, thx. Worked for me just fine.

@eploko

This comment has been minimized.

Show comment
Hide comment
@eploko

eploko 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. :)

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

This comment has been minimized.

Show comment
Hide comment
@ashchan

ashchan Jun 4, 2014

Wow works like a charm! Many thanks 👍 !

ashchan commented Jun 4, 2014

Wow works like a charm! Many thanks 👍 !

@afraser

This comment has been minimized.

Show comment
Hide comment

afraser commented Jun 5, 2014

Nice! Props @mhodgson.

@makzan

This comment has been minimized.

Show comment
Hide comment
@makzan

makzan Jun 5, 2014

Thanks @mhodgson. It works.

makzan commented Jun 5, 2014

Thanks @mhodgson. It works.

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 5, 2014

Contributor

This is great, thanks!

Contributor

koenpunt commented Jun 5, 2014

This is great, thanks!

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 5, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 5, 2014

Contributor

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>
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@mhodgson

mhodgson 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...

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...

@eddywashere eddywashere referenced this issue in typicode/katon Jun 8, 2014

Closed

Yosemite support #19

@adooylabs

This comment has been minimized.

Show comment
Hide comment
@adooylabs

adooylabs 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?

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

This comment has been minimized.

Show comment
Hide comment
@eploko

eploko 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.

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

This comment has been minimized.

Show comment
Hide comment
@mhodgson

mhodgson 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.

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.

@mhodgson mhodgson referenced this issue in code-mancers/invoker Jun 10, 2014

Closed

OS X 10.10 Yosemite Support (ipfw removed) #79

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 10, 2014

Contributor

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

Contributor

koenpunt commented Jun 10, 2014

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

@mhodgson

This comment has been minimized.

Show comment
Hide comment
@mhodgson

mhodgson 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 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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 10, 2014

Contributor

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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 10, 2014

Contributor

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

Contributor

koenpunt commented Jun 10, 2014

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

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 10, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@piersadrian

piersadrian Jun 12, 2014

Thanks for this @mhodgson! 👍

Thanks for this @mhodgson! 👍

@allaire allaire referenced this issue in hoodiehq-archive/local-tld Jun 12, 2014

Closed

Compatibility with Yosemite #26

@jimbocortes

This comment has been minimized.

Show comment
Hide comment

thanks @mhodgson !

@joeblau

This comment has been minimized.

Show comment
Hide comment
@joeblau

joeblau Jun 18, 2014

This works 👍 thanks @mhodgson

joeblau commented Jun 18, 2014

This works 👍 thanks @mhodgson

@idyll

This comment has been minimized.

Show comment
Hide comment
@idyll

idyll Jun 19, 2014

This addresses one of the issues - deprecation of IPFW.

But as far as I can tell there is something else going on that prevents Yosemite from working "offline" - and this was working in Mavericks.

I think it has to do with the DNS, possible it's not working at all either, but I haven't had time to look.

idyll commented Jun 19, 2014

This addresses one of the issues - deprecation of IPFW.

But as far as I can tell there is something else going on that prevents Yosemite from working "offline" - and this was working in Mavericks.

I think it has to do with the DNS, possible it's not working at all either, but I haven't had time to look.

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 19, 2014

Contributor

@idyll I have no issues with the DNS when working offline in Yosemite.. But I add the rule to the com.apple/250.ApplicationFirewall anchor instead of to a newly created one:

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

koenpunt commented Jun 19, 2014

@idyll I have no issues with the DNS when working offline in Yosemite.. But I add the rule to the com.apple/250.ApplicationFirewall anchor instead of to a newly created one:

echo "rdr pass on lo0 inet proto tcp from any to any port 80 -> 127.0.0.1 port 20559" \
| sudo pfctl -a 'com.apple/250.ApplicationFirewall' -f - -E
@hajder

This comment has been minimized.

Show comment
Hide comment
@hajder

hajder Jun 20, 2014

After upgrading to 10.10 update 1.0 I had to redo sudo pfctl -f /etc/pf.conf and sudo pfctl -e, not sure if this is an upgrade or a restart thing. Anyone having the same?

hajder commented Jun 20, 2014

After upgrading to 10.10 update 1.0 I had to redo sudo pfctl -f /etc/pf.conf and sudo pfctl -e, not sure if this is an upgrade or a restart thing. Anyone having the same?

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 20, 2014

Contributor

@hajder yes this is normal, because pfctl -e enables the firewall. But if you look at @mhodgson's comment above (with the excerpt from the manual) you'll see that -e is not the recommended way of enabling te firewall/packet filter.
Try the command in my previous comment

Contributor

koenpunt commented Jun 20, 2014

@hajder yes this is normal, because pfctl -e enables the firewall. But if you look at @mhodgson's comment above (with the excerpt from the manual) you'll see that -e is not the recommended way of enabling te firewall/packet filter.
Try the command in my previous comment

@idyll

This comment has been minimized.

Show comment
Hide comment
@idyll

idyll Jun 20, 2014

@koenpunt yeah yours' is the correct way of doing things. I've had no issues with that approach.

When offline you can address for now by adding entries to your hosts file. But this is a bad hack, the idea solution is to figure out what's messing up DNS. I will try to look at that over the weekend.

idyll commented Jun 20, 2014

@koenpunt yeah yours' is the correct way of doing things. I've had no issues with that approach.

When offline you can address for now by adding entries to your hosts file. But this is a bad hack, the idea solution is to figure out what's messing up DNS. I will try to look at that over the weekend.

@hajder

This comment has been minimized.

Show comment
Hide comment
@hajder

hajder Jun 21, 2014

@koenpunt @idyll @mhodgson now I started getting timeouts most of the time (but not always) just like #383

hajder commented Jun 21, 2014

@koenpunt @idyll @mhodgson now I started getting timeouts most of the time (but not always) just like #383

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jun 21, 2014

Contributor

@hajder this can't be related to the firewall, maybe something else in Yosemite has changed?

Contributor

koenpunt commented Jun 21, 2014

@hajder this can't be related to the firewall, maybe something else in Yosemite has changed?

@acmeyer

This comment has been minimized.

Show comment
Hide comment
@acmeyer

acmeyer Jun 23, 2014

@mhodgson worked for me as well 👍

acmeyer commented Jun 23, 2014

@mhodgson worked for me as well 👍

@jimbocortes

This comment has been minimized.

Show comment
Hide comment
@jimbocortes

jimbocortes Jun 24, 2014

Everytime I reboot my computer, pow stops working. I have to reload the rules into pf and enable pf again.

Everytime I reboot my computer, pow stops working. I have to reload the rules into pf and enable pf again.

@allolex

This comment has been minimized.

Show comment
Hide comment
@allolex

allolex Dec 6, 2014

It's odd that this error is still not resolved. I've now installed Pow in so many different way on my Yosemite system and port 80 was still not being redirected to 20559. I ran the command suggested above by @koenpunt and Pow is now working. I have no idea why using the pre-existing pf anchor is necessary to get it to work, but it does:

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

I've put this into a file called /Library/LaunchDaemons/cx.pow.firewall-custom.plist so that it loads on startup.

<?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>Label</key>
        <string>cx.pow.firewall-custom</string>
        <key>ProgramArguments</key>
        <array>
                <string>/bin/sh</string>
                <string>-c</string>
                <string>
                  sysctl -w net.inet.ip.forwarding=1;
                  echo "rdr pass proto tcp from any to any port {80,20559} -> 127.0.0.1 port 20559" | pfctl -a "com.apple/250.ApplicationFirewall" -Ef -
                </string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>UserName</key>
        <string>root</string>
</dict>
</plist>
  1. Install Pow normally, either via homebrew or curl get.pow.cx | sh.
  2. Create a .plist file with the above content.

It should "just work". 😉 cough

allolex commented Dec 6, 2014

It's odd that this error is still not resolved. I've now installed Pow in so many different way on my Yosemite system and port 80 was still not being redirected to 20559. I ran the command suggested above by @koenpunt and Pow is now working. I have no idea why using the pre-existing pf anchor is necessary to get it to work, but it does:

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

I've put this into a file called /Library/LaunchDaemons/cx.pow.firewall-custom.plist so that it loads on startup.

<?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>Label</key>
        <string>cx.pow.firewall-custom</string>
        <key>ProgramArguments</key>
        <array>
                <string>/bin/sh</string>
                <string>-c</string>
                <string>
                  sysctl -w net.inet.ip.forwarding=1;
                  echo "rdr pass proto tcp from any to any port {80,20559} -> 127.0.0.1 port 20559" | pfctl -a "com.apple/250.ApplicationFirewall" -Ef -
                </string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>UserName</key>
        <string>root</string>
</dict>
</plist>
  1. Install Pow normally, either via homebrew or curl get.pow.cx | sh.
  2. Create a .plist file with the above content.

It should "just work". 😉 cough

@zirni

This comment has been minimized.

Show comment
Hide comment
@zirni

zirni Jan 6, 2015

@allolex solutions worked for me.
But needed to restart my dns resolver as suggested on pow's troubleshooting site
https://github.com/basecamp/pow/wiki/Troubleshooting

$ scutil --dns
$ sudo touch /etc/resolver/dev # did the trick

zirni commented Jan 6, 2015

@allolex solutions worked for me.
But needed to restart my dns resolver as suggested on pow's troubleshooting site
https://github.com/basecamp/pow/wiki/Troubleshooting

$ scutil --dns
$ sudo touch /etc/resolver/dev # did the trick
@sescotti

This comment has been minimized.

Show comment
Hide comment
@sescotti

sescotti Jan 7, 2015

If this solution is preventing Tomcat to start, com.pow file should look like this:

rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 443 -> 127.0.0.1 port 8443
rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 8080 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 8443 -> 127.0.0.1 port 8443

sescotti commented Jan 7, 2015

If this solution is preventing Tomcat to start, com.pow file should look like this:

rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 80 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 443 -> 127.0.0.1 port 8443
rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 8080 -> 127.0.0.1 port 8080
rdr pass on lo0 inet proto tcp from any to 127.0.0.1 port 8443 -> 127.0.0.1 port 8443

@superfighter

This comment has been minimized.

Show comment
Hide comment

@autosquid autosquid referenced this issue in Homebrew/legacy-homebrew Jun 4, 2015

Closed

pow formula behave different from official install #40380

@onedanshow

This comment has been minimized.

Show comment
Hide comment
@onedanshow

onedanshow Jun 30, 2015

@allolex Thanks for posting your solution! I was doing the same thing

@allolex Thanks for posting your solution! I was doing the same thing

@brewster1134

This comment has been minimized.

Show comment
Hide comment
@brewster1134

brewster1134 Aug 5, 2015

so should this work out of the box now with 0.3.0? i have tried several of these solutions manually, but to no avail.

so should this work out of the box now with 0.3.0? i have tried several of these solutions manually, but to no avail.

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Aug 6, 2015

Contributor

Why would you still be using 0.3.0? 0.5.0 is the latest version of Pow.

But, if 0.3.0 uses the same port, which I guess it does, then the PF rule should work just fine.

What's your OS version?

Contributor

koenpunt commented Aug 6, 2015

Why would you still be using 0.3.0? 0.5.0 is the latest version of Pow.

But, if 0.3.0 uses the same port, which I guess it does, then the PF rule should work just fine.

What's your OS version?

@brewster1134

This comment has been minimized.

Show comment
Hide comment
@brewster1134

brewster1134 Aug 6, 2015

sorry that was a typo... i am on 0.5.0. OSX 10.10.4

sorry that was a typo... i am on 0.5.0. OSX 10.10.4

@aguynamedben

This comment has been minimized.

Show comment
Hide comment
@aguynamedben

aguynamedben Aug 27, 2015

FWIW @zirni's DNS reset solution worked for me. I'm not sure why this DNS fail happens.

$ scutil --dns
$ sudo touch /etc/resolver/dev # did the trick

One other thing to look out for... my zsh/bash config (oh-my-zsh) periodically self-checks for updates when a new shell is started. If if finds new updates, it goes into a "Do you want to upgrade? Y/n" prompt

If I restart pow during a time when zsh decides it needs to update itself, pow hangs. I have to ps aux | grep pow, kill <pid>, etc. Then open a new tab in iTerm, agree to the updates, then start pow again. It looks like pow runs within your shell, so if anything is keeping your shell from starting and handing pow control, that could be causing silent/failed/hanged starts.

FWIW @zirni's DNS reset solution worked for me. I'm not sure why this DNS fail happens.

$ scutil --dns
$ sudo touch /etc/resolver/dev # did the trick

One other thing to look out for... my zsh/bash config (oh-my-zsh) periodically self-checks for updates when a new shell is started. If if finds new updates, it goes into a "Do you want to upgrade? Y/n" prompt

If I restart pow during a time when zsh decides it needs to update itself, pow hangs. I have to ps aux | grep pow, kill <pid>, etc. Then open a new tab in iTerm, agree to the updates, then start pow again. It looks like pow runs within your shell, so if anything is keeping your shell from starting and handing pow control, that could be causing silent/failed/hanged starts.

@brewster1134

This comment has been minimized.

Show comment
Hide comment
@brewster1134

brewster1134 Aug 29, 2015

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

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

@nodesocket

This comment has been minimized.

Show comment
Hide comment
@nodesocket

nodesocket 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

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Oct 24, 2015

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@krishnarohitreddy

krishnarohitreddy Nov 19, 2015

thank you this worked for me :-)

thank you this worked for me :-)

@TimothyFitz TimothyFitz referenced this issue in canvasnetworks/canvas Nov 23, 2015

Open

ipfw was removed in 10.10 #8

@Wissam-Halimi

This comment has been minimized.

Show comment
Hide comment
@Wissam-Halimi

Wissam-Halimi Nov 25, 2015

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

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

@davidhq

This comment has been minimized.

Show comment
Hide comment
@davidhq

davidhq Jan 11, 2016

Thank you so much...

davidhq commented Jan 11, 2016

Thank you so much...

@YiHuaTian

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian 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

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

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian Jan 27, 2016

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

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

@YiHuaTian

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian 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

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

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian 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"

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jan 27, 2016

Contributor

You shouldnt mess with /etc/pf.conf IMHO

Contributor

koenpunt commented Jan 27, 2016

You shouldnt mess with /etc/pf.conf IMHO

@YiHuaTian

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian Jan 28, 2016

@koenpunt What do you mean?

@koenpunt What do you mean?

@YiHuaTian

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian Jan 28, 2016

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

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

@YiHuaTian

This comment has been minimized.

Show comment
Hide comment
@YiHuaTian

YiHuaTian 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?

@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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Jan 28, 2016

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@davidmoore-io

davidmoore-io Feb 22, 2016

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

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

@grempe grempe referenced this issue in 45678/miniLockLib Mar 20, 2016

Merged

Friendly amendments to pull #15 #17

@wujinhong

This comment has been minimized.

Show comment
Hide comment
@wujinhong

wujinhong 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)

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

This comment has been minimized.

Show comment
Hide comment
@uxp

uxp 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

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

This comment has been minimized.

Show comment
Hide comment
@bjensen

bjensen 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...

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

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Apr 4, 2018

Contributor

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

Contributor

koenpunt commented Apr 4, 2018

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

@bjensen

This comment has been minimized.

Show comment
Hide comment
@bjensen

bjensen Apr 7, 2018

@koenpunt puma-dev works with unicorn?

bjensen commented Apr 7, 2018

@koenpunt puma-dev works with unicorn?

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Apr 7, 2018

Contributor

@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?

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@bf4

bf4 Apr 7, 2018

bf4 commented Apr 7, 2018

@koenpunt

This comment has been minimized.

Show comment
Hide comment
@koenpunt

koenpunt Apr 7, 2018

Contributor

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

Contributor

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.