@chpalmer: I generally tell people to put everything back to default (no port forwards/ no static ports..) Instead make inbound firewall rules from the SIP server to the phones behind the firewall.  You will also want firewall rules that allow the RTP streams from whichever server(s) provide those streams inbound.. Also- if your phones are going out for a provisioning files then make sure you have /system_advanced_firewall.php  TFTP proxy set for your phone interface. I can provide some screenshots of some of my sites here if you need.. I doun't understand how I can have inbound rules to more than one phone. For example if the port is 5060, I can only forward that to one IP address right? I know I'm missing what you're saying here. Can you explain a bit further. I appreciate it.

Right. And that page specifically states to use them only if you know what you are doing and know why they are needed. They are not the "recommended settings." I would still re-enable scrubbing and set the firewall mode from conservative back to normal. Both of those are rarely necessary as well.

I'm not sure that it's double natting due to pfSense. I thought that the remote APs created a tunnel between the AP and the controller either local or on your intranet that's connected to the internet, is the double NAT occurring where controller is located ? http://www.arubanetworks.com/assets/ds/DS_AP200Series.pdf http://www.arubanetworks.com/products/networking/remote-access-points/ http://www.arubanetworks.com/assets/eo/EO_RemoteAccess.pdf

@chpalmer: @cmb: Correct. It never has been the case. pf rdr (port forwards) always override anything listening locally on the system. What some people probably end up with in that case is the HTTP->HTTPS redirect cached in their browser from before reflection was enabled, and browsers really want to hold onto those redirects. So then they always get sent by their browser to HTTPS when trying to get to the HTTP, don't have the HTTPS port forwarded, so hit the GUI (because they're actually browsing straight there, their browser just doesn't make that clear that it's not even trying the HTTP connection anymore). They screw around with it long enough, and refresh enough times, that the browser gives up on the redirect. Then "disabling the redirect fixed it!" because they didn't change anything else, so surely that had to be it, right? No. Im trying to remember where I got this "bad behavior" but would have only taken once for me to hold onto it.  :o ;D    Since I use a different port on the GUI anyways Ive never really tested it after the first time. Not to resurrect any posts here… But I ran into the same issue as OP. Only my NAT rules were correct (as proposed by Derelict). In my experience, on PfSense 2.3.4, PF RDR does not take precedence, and will cause you to get locked out of the gui if you configure it to forward 80 to a different server. The only thing that works, is as ChPalmer describes; Change the port the WebGUI is listening on and disable the redirect, so it doesn't keep listening on 80. Then, and only then, the PF succeeds. To reflect on CMB; It was not a browser cache in my case. For the OP's 'other' issue; You probably forgot to open 80 somewhere on your destination server (or along the route). Why this comment? If PF RDR should take precedence always, which would be a great feature, it is not working. Maybe a bug fix is in order. Thanks all.

Ok so now to figure out why changing the router would cause the server to reject the connection… I made no changes on that side.

Is the current subnet routed? If so then just subnet it. Break it into 2 /28 you can use 1 as vips on wan for 1:1 and use the other /28 for behind.  Or /28 and 2 /29's… How ever you want to break it up... But your /27 actually needs to be routed to you.. Not just you attached to it. So you have another transit network and this /27 is routed down that transit.  If so then yeah this is easy peasy lemon squeezy..

That is very astute of you and is the exact problem! I installed nginx on the internal webserver and started that instead. Flawless port forward after! The problem is in my apache config that I forgot to go back and clean up when I mas tinkering. Thank you very much, ndemou!

I've had that happen numerous times and finally found this post. Identical log messages (apart from other IPs).  Can't figure out why DHCPDISCOVER is not sent to 255.255.255.255 anymore but to a fix IP that is not routable. Yes, my ISP goes down more than what I like but not being able to recover leaves me standing without connectivity until I save my WAN IF settings and reload. Anyone?

Per your drawing that 172.20.1/24 is clearly a TRANSIT network…

Apologies for the really late reply. Everything seems to work now as intended. I was able to configure it properly with CARP and its smooth. Only thing is I was only able to get it working with manual NAT not hybrid. As always, thank you for your support.

and do not connect, do you have any other ideas? Did you reconfigure IIS so that it thinks its using your public address and not its LAN address like I said?  For example, when I used to use vsftpd, you had to configure passive like this: pasv_enable=YES pasv_min_port=50000 pasv_max_port=50100 pasv_address=a.b.c.d where 50000-50100 is your passive range and a.b.c.d is your WAN IP address.

No, definitely not bonded with the modems. At their end they have proprietary routers that just send IP packets down both lines, balancing them based on the sync speed of the lines. They will happily sell you a similar router, to connect to two VDSL/PPPOE modems. I'm just trying to avoid spending the $700 they ask for their router (and I'd have rather have used pfSense if it was an option). They are a very unusual ISP ;) You can actually achieve much of what I want with three basic consumer routers. Use two with their own VDSL ports to route from the lines (both using the same WAN address), with a third router behind them doing the firewalling and NAT (with one of the other routers set as its default gateway). That doesn't get you upstream bonding though. Anyway, thanks for your input, clearly pfSense can't meet my admittedly unusual requirements and it is time to try another route (dd-wrt if I can, if not my own Ubuntu build, failing that $700 router from ISP).

And the firewall logs will not include passed traffic unless you explicitly tell that pass rule to log. You need to be looking exclusively at packet captures, pretty much.

thank you

would need more details to be able to make a determination. Glad it's fixed.

Exhaustive list of other things to check here. When it works from the same subnet but not from others it is almost always either the local firewall on the target or the default gateway of the target is wrong. https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting

You should not have to do anything to use any cell booster behind pfSense in its default configuration. If you have messed about with the default outbound NAT static port on port 500 or something, maybe you might have to undo that. They generally initiate an OUTBOUND IPsec connection to the cell provider. Nothing should be required on the firewall. No special rules, no special port forwards, etc. They generally require a good GPS signal and can take a LONG TIME to sync up. The best we can try to do if it is not working is interpret the specific instructions or guidance they provided. You would need to post that. Port mapping rule for UDP/4500 on WAN interface -> 10.42.0.2:UDP/4500 You do not need this for an outbound connection. Manual outbound NAT configured - only a rule for * -> WAN address configured for the 10.42.0.0/30 subnet Why manual? Automatic will capture that. Currently an additional rule for UDP/any going to WAN interface Zero idea what that means. Post the rule. I realize those were posted a while ago by someone else but you stated you did the same thing.