Awesome! Thanks for the info… Will ask them.... Thank you guys for everything!!! problem solved....

OK Feeling quite stupid! I have enabled NAT reflection and all seems to work, perhaps it always did for traffic arriving on the WAN!! Thanks for your help, Ernie

You can't effectively do what you're trying to do, because of the way pf works. NAT happens before filtering, so the 1:1 for port 80 and the port forward for 30123 look identical to the firewall rules, so they are both allowed. The correct thing to do in this case would be, as johnpoz said, to make the service bind to port 30123 and not rely on a NAT redirect. Either that, or ditch the 1:1 NAT and just use port forwards. Actually I take that back - there may be another way: Add a port forward for 80->80 like you have for 30123->80, but on the 80->80 rule, check "No RDR (NOT)".

CARP works just fine as well. You just have to make sure that the CIDR is in the same subnet /29 in this case. Course, this is the same for IP Alias as well. CARP will let you setup clustering firewalls. If you know you don't need this for this use, then I would use IP Alias.

ok, I found that. trick is in the NAT reflection settings. Working config is to enable NAT reflection (either in system advanced settings, either in rule-specific settings) AND to enable tick "Automatically create outbound NAT rules…" in system advanced settings. With this adjustment I see following packets in tcpdump (actually this is one ping packet):         13:59:07.684110 IP 192.168.0.68 > 1.1.0.1: ICMP echo request, id 512, seq 45843, length 40         13:59:07.684172 IP 192.168.0.254 > 192.168.0.10: ICMP echo request, id 29846, seq 45843, length 40         13:59:07.684299 IP 192.168.0.10 > 192.168.0.254: ICMP echo reply, id 29846, seq 45843, length 40         13:59:07.684313 IP 1.1.0.1 > 192.168.0.68: ICMP echo reply, id 512, seq 45843, length 40 and without a second tick i get:         14:00:37.735766 IP 192.168.0.68 > 1.1.0.1: ICMP echo request, id 512, seq 46099, length 40         14:00:37.735820 IP 192.168.0.68 > 192.168.0.10: ICMP echo request, id 512, seq 46099, length 40 mailserver then replies directly to my pc in local network, but it doesn't expect this echo reply…

The subnet specified for the WAN side of the inner firewall should have been 192.168.1.0/24.  Once I fixed that, all is well.  Problem fixation. Thanks to all,

I'm not understanding your question fully.  You want to screen ALL outbound traffic to web sites right?  So what is not working, and what happens instead. You are correct that you cannot redirect traffic on one network segment back to a host in the same segment, unless if appears to be addressed outside the segment so that it gets routed to the gateway.  Think about it:  why would the switches and hosts bother addressing the gateway firewall if they are trying to reach a sibling host on their same subnet?  So hosts on the LAN are welcome to access their peers' http port without the firewall, but I think this is not your main concern. Are you trying to do what captive portal does, maybe?  Might look at that.

Thanks again! While sleepily changing IPs on the reverse proxy, I realised this would mean having to change how I ssh to the vms behind pfsense from the mac host, which is 192.168.1.1, and I'd also have to change IPs of the vms network adapters. I'll have to forgo the flexibility and security of nating and try bridging WAN and LAN again. Hopefully I can get it going now that I have network adapters currently working.

Yes that's possible. You have to have one rule per WAN, so that's two port forwards (they specify the public IP and that's different on each, hence the requirement).

Hey guys, Sorry meant to get back to you - finally this one out.  Turns out that several stale MAC addresses on indirectly connected Cisco switches proved to be the issue (this would have been caused via my inter-vlan routing configuration). Basically the pfsense instances having the problem were arping out for the administratively defined gateway.  These ip addresses were once in use on another portion of my network - the old MAC addresses were therefore still present in some (not all) of the multi-layer switches.  As a result, the virtual MAC of the gateway that the problem pfsense instances were seeing was forever changing (at least once a second as I found it in the pfsense logs).  Flushing the arp tables on the connecting switches and bringing the gateways back into the configuration with a new virtual mac address resolved the issues noted at the firewall layer. :-) I'm not sure at face value without testing but I guess the same problem could arise if you aren't careful with an HSRP/VRRP configuration to be used for a pfsense gateway (since the likes of HSRP uses virtual MACS also).  Just a wee heads-up for anyone that might find it useful! Cheers, ehamil16

Sorry. Misinterpreted what was being asked for.

On the wan rules you don't need the 192.168.22 or 44/24 listed there. according to the diagram, those networks should not be on that side of the FW. plus the wan rule to block private ips above ensures that it will be blocked anyway.

Excellent! Thats worked, you are a star!!!! Thank you very much for a quick resolution- i was almost about to give up on Pfsense! Thanks

Hello, I do NAT but after some time has m external ports that I created stop working. What can be the problem? Do you have any examples?

@suicidegybe: My question is can I send my port 80 request to some type of DNS serveice have it sent to my network under a diferent port and then once back inside my network sent to port 80 again. I know crazy but to get port 80 open it will at least double my monthly isp bill. If you know a way i'm all ears. DNS doesn't do that… You can and setup a NAT translation rule: enable inbound port 8080 and set "Redirect target port" on the NAT rule to port 80 Then you can visit: http://your_external_ip:8080/ That will be redirected to port 80 on your WHS.

Pretty sure he's looking for something like ProxyPass for apache.  I don't think there is a sutible module for pfSense, but I've never really looked for one before either.

Ok using the above info i found that it the ip address ending in 104 was not my old CSS server.  It was the UT3 server that had a port alias of 27000:28000. Removed it, and redid those port forwards and its all good. However it still doesnt explain the weird stuff I was seeing with the FTP servers.  Though that seemed to have stopped this morning as well. Note to self…. no working on the firewall at 11 at night when you're too tired to see the most obvious things.