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

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.

I'm seeing this exact same issue, can't connect to team speak server from external.
Internal is working fine.
Any help would be much appreciated.

I have 1:1 Nat from my external IP to my Web Server 192.168.10.120

The firewall rules for port 80 to my web Server works ok

2016-01-20.png
2016-01-20.png_thumb

@Derelict:

Why are you messing around with 1:1 NAT? Just create an outbound NAT rule that uses the proper VIP based on the source addresses of the traffic.

Duh… thanks. That worked perfectly.

Rebooting my Comcast modem solved the issue!  Thank you VERY much!  ;D

You don't need to do any port forwards for microcells.

There is a bug where pfsense sometimes doesn't NAT outbound ISAKMP (udp/4500) packets if they are fragmented (they frequently are). To my knowledge, this bug has not been acknowledged by the maintainers (but then again, I haven't looked too deeply).

My solution was to disable packet scrubbing, and delete the NAT rule for IPSec that is automatically created (you have to change from automatic rules to manual to be able to delete it).

This thread: https://forum.pfsense.org/index.php?topic=103503.0 mentions other possible fixes which seem to contradict my fix.

@johnpoz:

POA?  You mean SOA (source of authority) ?

Sorry - wrote in a hurry and had a brief brain-melt. Yes - meant SOA.

Some information on what forwarders your name servers are each using would probably help, too.