How does it "not work"?

Can you show a screenshot of your rules?

I'm having the exact same problem.  I'll try the backup/edit/restore to fix, but I'm wondering if there is a fix in the package or source that I should log somewhere?

Actually, you can mix 1:1 and port forwards on the same IP.  The port forwards can be used when you want to override specific ports.

Edit:

Not sure if that's specific to 2.0 or if earlier versions did that as well.

sorry if this is sovled
but have you checked it sounds like you have to servers listening on port 80
set one server to :8080 it should work
i found that which ever server is in the nat list first becomes default if there is a conflict
just a suggestion from trial and errror

Not sure about doing it remotely but if you can access the console you should be good… Try to re-assign the interfaces... If that doesn't work... you could reset to defaults and restore a backup config.xml... Not sure of any other easy way to fix it... You could manually edit the config file via the console

I understand what you mean, that some ISP provides a modem with bridging mode and other does not. I am pretty sure my connection is in bridge mode because I was able to established 1:1 NAT for our Mail server and it does works. So all our outbound email uses an IP address I specified on 1:1 NAT not the WAN IP address.

If the ip changes gracefully e.g As a result of a routine dhcp renew I don't see why it should consider any downtime to have taken place.

Then your ISP is port forwarding at least TCP port 80 to your unroutable WAN address. If they are forwarding all port and protocols to you then they are probably bridging you. However, there is no way you can be reached from the internet on your as configured WAN address.

www.the-halls.ca resolves to a public IP address of 69.49.41.150, but you already knew that.

http://forum.pfsense.org/index.php/topic,33566.msg174126.html#msg174126
^^^ how to install/setup pound

"Proxy Server with mod_security" and varnish which is supported on the beta x64 version.

scratch this, I have worked it out. I assumed that the interface would be for the VLAN rather than the external.

stupid mistake.

Thanks a lot jimp. That was the issue, I removed the port forward and all is well.

You have to access the IP you have on the WAN, not the IP of the actual server.

I see, that's silly :(

Thank you, jimp!

…thank you again for the comments.  This is why I posted.  Why the the "unresolvable aliases" and how do I fix that ?  The rules were automatically created when I NATed, why are they giving me that error ?

Also, all suggestions on setting up the FTP helper say, enable it on the WAN.  So, do I enable the helper on both ? or just my DMZ ?  Please understand I am not a network expert, though I am eager to learn.  This is my house where I also have a small office.  I very much appreciate any help you can give.

So, here is what I just tried -- I disabled the helper on the WAN, and enabled it on the DMZ.  I was able to ftp and get the login screen, but logged me out immediately after typing my password.  I did this 3 times with the same result.  My firewall log shows allowed connection to my FTP server, but nothing else.

Cheers,  -NJ

@bshack:

So now I feel a bit silly, but will post this just in the event anyone else can benefit from it.  It seems that if you leave the default NAT mode set to Automatic it put all of the VLAN's on the Internal interface into a NAT table that overrode any of the rules put in after that.  Once I switch the NAT mode to manual, it started working perfectly.

FYI- That is expected behavior. If you are on automatic, the manual rules are ignored. In order to use the manual rules, you have to be on manual outbound NAT.

EDIT: I modified the text on the page on 2.0 to be a bit more clear, spelling out that in automatic mode the rules are ignored.