So I decided to remove everything and start from scratch. I believe I have removed everything and go to remove the alias and I get "Cannot delete Alias. Currently in use by"  In use by what?  

silly me  ;D I fixed it by moving the NAT rule for the FTP  below the SIP lolz… [image: Clipboarder.2015.09.03-015.png] [image: Clipboarder.2015.09.03-015.png_thumb]

So I guess I am stuck with a VPN go go through it. But I can simplify the vpn for user based authentication via an AD or Radius server on the back side. thoughts ? thanks

I never would have guessed that.

Yes, I was hoping to KISS but since it doesn't work straight out of the box I've had to delve in deeper. The SIProxd was a test since I wasn't getting anywhere with Firewall NAT'ing. The package notes say it is not needed as much with newer PBXes. My thinking was that the Allworx 24x is a bit on the older side so it may still apply. I've since removed the package. A basics NAT question - I need entries in both Rules and NAT correct? Also when trying NAT> Outbound I chose Manual as well as Hybrid with no positive effect.

haha yeah i made my own guide  :) let me know how it goes http://www.mediafire.com/view/j25mbohmmxvt7g4/Installing_ELK_on_Lubuntu_15.0.4_ON_HYPER-V.docx

Glad you got it up and running. As you've seen the forum can be a great resource. It might be nice if you update the Subject of your first message with a [Solved] tag so that others can benefit. Again, welcome to pfSense!

Ok for what?  What part do you not understand that nat reflection is a hack and to be avoided.. Why don't you just use your local IP or setup name resolution to resolve whatever it is your trying to get on that public to resolve to your local.. This is much better then sending packets out to your cisco, to be sent back in to pfsense to be sent back into whatever when that whatever is connected to the same switch you are.

I couldn't get the relevant messages to show up in the GUI.  Turns out it was the Bogon rule blocking the traffic, since it wasn't updating properly.

Port forwards override 1:1 NAT, so you can play a bit of a trick. Keep the 1:1 NATs in place, even though the second entries are non-functional. Add port forwards for the inbound traffic on the new VIPs, those will work fine. When the time comes, remove the old 1:1 NAT and port forwards and things should keep working fine.

Ahhh! Right, thanks mate that fixed it. I appreciate the help. Awesome!

It's considered good form to show others the solution to your problem if you managed to figure it out yourself. This may help others: https://doc.pfsense.org/index.php/DNS_Rebinding_Protections

@jimp: @MatthewH: Is it possible to have the manual mappings override the automatic rules when using hybrid outbound nat? That is the entire purpose of Hybrid mode. User rules are respected first, then automatic follows. So only put in your rule(s) for using the VIP(s) you want and switch to Hybrid mode. That's what I thought, but it didn't work that way. I'm on 2.2.4. I'm using the outbound nat so 1 subnet will use a VIP. I setup using Hybrid mode, cleared all states for the subnet, then used a website to check my external IP and it returned the main interface IP. I ended up switching to the full manual outbound NAT so there wouldn't be 2 rules for that subnet and then it worked like it should. Maybe a bug?? Thanks for the reply.

Thanks. Let's look at these rules. Rules 1 and 2 are for the loopback address subnet. How/why does anyone expect/want/need a network device to pass any of these addresses? Why do these rules exist? Rules 3 and 4 look fantastic. And I totally get the verbiage about address pools on this page: https://doc.pfsense.org/index.php/Outbound_NAT, and how that relates to groups of LAN users using different WAN IP addresses (so WAN address doesn't run out of resources). I also suspect I can use address pools for my DMZ. E.g. 8 - 9 pool outbound to VIP 113, 16 - 17 pool outbound to VIP 114, etc (but I could be completely wrong about that too). Rules 5 and 6 are the problem. I thought the more specific rule (port 500) wouldn't affect the broader rule I constructed. It was my guess that if I put my rule before the port 500 rule, then the port 500 rule would never come into play. Is this wrong? In general, it's my understanding that rules for other networks (e.g. loopback and LAN) have no effect on DMZ rules. Is that also wrong? I do understand how the order of rules is significant, but I didn't see an issue with these rules. Apparently pf and pfSense make assumptions. For example on this page: https://doc.pfsense.org/index.php/Firewall_Rule_Basics it says "Where no user-configured firewall rules match, traffic is denied." (2nd paragraph)–which is why there's no explicit block everything rule at the bottom of the list. Are there other built-in assumptions I've missed? Thanks again for your help.

And try the search box on the forum.

I'm a pfSense newbe, but I know networking in general. On your WAN side you'll have one of your static IPs assigned to pfSense, along with the /28 to tell it the size of your subnet, and the gateway address (the address of your modem). My ancient SonicWALL was just smart enough to be stupid. It knew the 0th, 15th, gateway, and it's own address were unavailable, and so the other 12 addresses in that /28 subnet must belong on the LAN–so it set itself to bridging mode (you could override that with NAT if desired). pfSense is much smarter than that and so it assumes nothing. What if there were other hosts between it and the gateway? Therefore you must set virtual IPs to tell it that when it sees one of them, it must do something with it. There is a bridging mode in pfSense, but my neighbor suggested 1-to-1 NAT would be better. Or one could use port forwarding, in which case rules can be auto-generated. Three choices, but all require virtual IPs be set first. To set virtual IPs go to "Firewall / Virtual IPs". It's a little hard to find bridging in the GUI, so here's a page in the DOCs that describes it. https://doc.pfsense.org/index.php/Interface_Bridges