It appears someone was able to accomplish this 9 years ago, but the instructions don't translate well to the current version. https://forum.pfsense.org/index.php?topic=4225.0 Has anyone been able to setup a transparent proxy on pfsense that forwards traffic to an internal squid server but preserves the source IP addresses?

Have a look at /index.php?topic=106305.0, particularly sections 9 and 10.

Thank you for responding. Now I need a little help to get my head around how I would configure that in. Would I construct a series of rules like the following using what I wrote in my original post Block not 79.135.125.0/24 destination xxx.xxx.xxx.xxx then Block not 87.238.72.128/26 destination xxx.xxx.xxx.xxx etc then last would be the NAT which would anything to xxx.xxx.xxx.xxx port 5000 Tried the above and to see if it worked. I removed the NOT tick so as I understand it then traffic should have been blocked  the address blocks. However, I found that traffic was getting through on the final rule/nat. I had the rules listed such that the block rules were before the NAT rule. So I am missing something so can you please clarify your post. Moving from IPCOP to pfsense has been relatively trouble free apart from this issue.

Your doing it wrong is all I can say.. Your shared printer doesn't show any issues with nat.. "except that there's one network printer and no need to buy another, so it's given a mapped IP that allows it to appear as 192.168.1.2 from the "home" and also as 10.1.1.2 from the office." Why do you need/want to nat between these networks??  Please give one actual logical reason why you would nat between these 2 networks..  I have multiple network segments in a home..  Why would I nat between my segments??  Why in the world would I have to map the printer to 10.1.1.2  When I can just access it via 192.168.1.2 while creating firewall rule.. Please give an example that actually makes sense where you question comes into play..  There are millions and of networks available in rfc1918 space.. For what possible reason would I nat those in the same location..  And if the same space is being used remotely or even lets call it the same building where you happen to use 192.168.1.0/24 and someone else used 192.68.1.0/24..  Why do we need to talk and how are we talking - there would have to be a transit network between us. So you freaking nat their 192.168.1.0/24 to 192.168.2.0/24 or any other space available in 1918…  Or one of you change your network would be the better idea.. Your question is a non issue because you can not give an example when it would ever come into play that would make sense... Your outbound rules manual come before auto, and manual can be adjusted.. Where exactly is there a problem??  This is outbound nat keep in mind, not inbound.  Your natting your clients behind your interface to your interface when they go out that interface.

You have two WAN rules both duplicating a forward to port 35060. From what I can see on your NAT rule table, one of these should be 5060. Your NAT rule is doing a port mapping from 5060 to 35060 internally, but your corresponding WAN firewall rule isn't specifying the correct target port.

Huh? What? That's totally… rereads OP :| lol whoops.

Any Windows or Linux client will have DNS query tools available. So connect one to your LAN and run the nslookup/dig command I mentioned earlier. Target an external DNS server in your query to see whether you get a response. If you can ping 8.8.8.8, for instance, but don't get a reply when running 'nslookup www.google.com 8.8.8.8' then I would look carefully at your firewall rules. If in doubt, post them and maybe someone can help further. Otherwise, I think we've just about exhausted all possibilities at this stage.

Hi for outbound NAT leave ports "ANY" not just "VOIP" alias. Should work.

Ok thanks, now it works…but..one last thing i put the name of the server so works with  site.domain.local but no with site.domain.com. Thanks for all!!! Ante

Again, when I publish the exact same environment (ie. just port 443) through TMG, without making any change to the Exchange setup at all, it works fine. My external URL's are setup to match the certificate and as such I can use OWA, ActiveSync and OutlookAnywhere when I publish it through TMG. Therefore I believe it's not in certificates or URL's. OWA is published through WAP as well, for Exchange only WAP is accesible from the WAN. WAP proxies the request to Exchange when preauthentication is used and forward it when no preauthentication is used. I'll fiddle around a bit and try to get some traffic captures. Thanks so far.

@fmillion: The 1:1 mapping might be useful, but it seems like I'd have to add 254 rules to the table by hand - one for each possible IP on the 192.168.1.0/24 LAN. No. You can map a whole subnet with just one 1:1 NAT rule. E.g. if you enter 172.16.101.1 at External subnet IP and at Internal IP select Network, enter 192.168.1.1 below and select /24 for the mask. This way 172.16.101.1 will be translated to 192.168.1.1, 172.16.101.2 to 192.168.1.2 and so on.

I don't do any NATs and I have an Asterisk PBX running behind pfsense just fine. The only thing I had to do was: 1. Register with DuckDNS for a dynamic DNS setup. 2. Configure pfsense to keep DusckDNS updated on what my public IP address is 3. Configure Asterisk so that it knows its outbound trunk connection is being natted, and that the public IP address can be found by looking up xxxx.duckdns.org

Got it sorted out. After working with my ISP, they explained that their equipment doesn't actually support bridged mode and they setup a DMZ sort ofand just call it bridged, and then they forward all traffic from public IP to private IP…when going through all of the settings, they realized they were forwarding the public IP traffic to the wrong private IP (the 192.168.20.33 IP) - they set it to the correct IP, and everything is working now. Thanks so much for everyone's help!

Are these servers listening on 443 in your dmz needed to be open to the public.. If not once you vpn you would have access with no need for forwarding. Keep in mind when you setup a reverse proxy behind your edge router/nat/firewall device like pfsense you need to make sure you don't run into a asynchronous routing issue.  This reverse proxy you use would most likely be best if on a transit network connecting it to pfsense, and then your servers behind that.  So not only does this reverse proxy need to proxy it also needs to route. Cleaner solution would be for sure to have another public IP to work with for your openvpn you want on 443.  Can you run one of these servers on a different port, say 8443 that you forward to 443 behind? And then let the port sharing of openvpn forward to the other server?

I figured this out (or so I think)… 1. Set up squid (adapted from http://www.squid-cache.org/Doc/config/http_port/) Edit squid.conf modify the http_port direct to include accel and allow-direct. 2. Add a port forward / destination nat rule (adapted from https://forum.pfsense.org/index.php?topic=39736.0) GUI -> NAT -> Port Forward tab > Add rule Interface: LAN Protocol: TCP Source: NOT <ip of="" squid="" box="">Source port range: any Destination: up to you Destination port range: from HTTP to HTTP Redirect target IP: <ip of="" squid="" box="">Redirect target port: <squid 3128="" port="">3. Add an outbound / source nat rule (adapted from http://tldp.org/HOWTO/TransparentProxy-6.html#ss6.1) GUI -> NAT -> Outbound > add rule Interface: LAN Protocol: TCP Source: Network / your LAN Net  ie 192.168.1.0/24 Destination: <ip of="" squid="" box="">Destination port: <squid 3128="" port="">Translation: Interface address No separate interface / subnet for the squid box required.</squid></ip></squid></ip></ip>

well your not going to be getting any mail once the ttl on your old mx expires since 25 does not seem open to your wan IP from my test. The owner of the IP has to change the PTR.

Yeah.  I think about it like this: Port forwards translate destination addresses and ports as connections come into an interface. Outbound NAT translates source addresses and ports as connections go out of an interface. You usually only use one or the other but you can do both.