Dansguardian uses squid to actually send and capture the request, and since your users aren't directly using squid, it only needs to listen on the loopback interface since Dansguardian is on the same machine.

By the way, I hope I posted this in the correct section/area

Improper caching the easiest way to break the Internet. It's best left to your ISP. Decent ISPs should't charge you for cached data from their internal network.

I don't understand what you're trying to do. Is 172.16.0.1 on the LAN side or a remote address from beyond the gateway on WAN side? What do you mean by redirect? If it's coming from the WAN side then I don't see how you can DNAT to the GW address since it has already passed the GW by the time it reaches pfSense. The rules on the WAN are only useful if the destination packet is for a host on one of pfSense's other interfaces and pfSense is performing non-NAT routing from WAN to LAN. The Manual Outbound NAT rules on WAN are also applicable for traffic originating from another interface and leaving through WAN. I believe you should be creating the DNAT rules on the GW host, not on pfSense.

Yes, got it working.  Very pleased with support forum assistance, big fan of PFSense. thanks for the pic.

@husterk: Thanks for the tips… any chance I could make this work without needing to modify the Cisco ASA settings? I may not have access to this device. I can't think how to do that - the Cisco needs to know somehow that the pfSense WAN IP is a gateway to 192.168.1.0/24 Your NAT solution is the standard way, essentially faking the pfSense LAN side address using a WAN side address that the Cisco is already happy to talk with. By the way, if you do change the Cisco to add a route to 192.168.1.1 then you will have trouble when you VPN in to the Cisco from your favourite cafe/friend's house that is using 192.168.1.0/24 locally. If possible, I would change the LAN subnet to something less common - out of the 10.0.0.0/8 space or 172.16.0.0/12 space or down the end of 192.168.0.0/16.

Nope - Mine works fine.  But thanks for the help.  ;)

You need to use Manual Outbound NAT and create a rule with source the network as VLAN3 that uses the desired Virtual IP Alias for translation. The order of the rules matter. If a higher rule matches it, it won't work.

Thanks. Got this working finally. Made a mistake in the outbound rule and that's whats caused the problem. BR Chris

Oh k. I have been told to stop playing with this. I accidentally made it so no one could play Final fantasy or War Thunder but they could still go to the web. Disabled the opt1 and everything worked again.  :o thanks for reading at least.

you may  do  run NAT off in bridged / transparent mode. I think I should be able to achieve

i ran a tcpdump on the wan interface to make sure the isp is not blocking the ports and they are open the wan interface are getting the connections its puzzling that pf sense is not matching the rules and forwards it.

Yeah - He knows that, but for unfathomable reason he doesn't want to do that.  Its strange but true.  He is well aware he could use the private IPs.  He just doesn't want to… Yeah - I know...  right?

To solve this more clean i would configure split DNS. Consider taking a look at this page: http://doc.pfsense.org/index.php/Why_can%27t_I_access_forwarded_ports_on_my_WAN_IP_from_my_LAN/OPTx_networks%3F The third option is about solving this in an experimental way when 1:1 NAT is in use.

@kejianshi: The only time I've seen pfsense drop connections willy-nilly is when packages were running to filter packets and cause them to drop.  Also seen connectivity killed when some equipment was running jumbo frames and other pieces were not compatible.  Bad connectors or cables?  Your configuration seems too simple to have big problems. Well, I was talking more about rogue packets (intercepted by pfSense instead of ASA) than lost ones. I do have 6-7 VLANs on my switch though, but if it the problem selvresolved after sometime so not it's difficult for me to track down the source of the problem.