I ended up just using the Host Overrides in DNS Forwarder as my split DNS solution since none of the other solutions seemed to work. From what I understand it's using a dnsmasq backend and likely just adding the entries to /etc/hosts

To get the behavior you want with OpenVPN, where reply-to sends the packets back the way they came in, you'll need to do the following (on the receiving side):

1. Assign/enable the OpenVPN interface from Interfaces > (assign). Set it to an IP type of 'none'
2. Restart the VPN (edit/save)
3. Move firewall rules from the OpenVPN tab to the new interface tab. No rules on the OpenVPN tab can match the traffic.

@Aksa0110:

…everything is up and running now...

dotdash you were right... wan and LAN on the same subnet = bad idea, i had to learn it the hard way, i have changed the LAN subnet and everything worked instantly

thank you for @eyeopener@

Yep. I'm a little late in the game on this one, but you definitely want all of your interfaces on a router to be on separate subnets. Good work figuring that out.

I'm assuming your WAN looks like a single block of IPs (/27 for example) rather than a routed WAN (/27 routed to a /30 on the WAN interface, for example).  I had the same confusion when I first switched to pfSense.

The reason you have to do a virtual IP is that the IP interfaces are separate from the Firewall (NAT/Rules/etc) at the OS level.

Also, having the 1:1 NATs on Virtual IPs allows you to do things like use CARP for failover between two boxes.

Which is my point about a hostile lan, if you consider it hostile - then sure run host based firewalls.  But you have to freaking configure them to do any sort of good.  And again why would you have 2??  If you not going to actually configure them - they are not going to do anything for you but cause headache and grief and more administration.  If you were configuring them you would of known hey - I want machines from source X to talk to my workstations have to edit the firewall configs to allow that.

Hi John,

Thank you for your input here. :D

I do appreciate your your time and effort in giving out advice. ;D

But would it be possible to type out your information is small
little bite size chunks, so that I can digest it quickly. :)

Ok, back to what I want to say…..

Yes, I know, one of my PCs from the hostile LAN was shifted to the
OPT2VIANIC network for testing internet connection.

So that PC used for testing has got a software firewall loaded.
That is why there is so much grief happened to me.

Yes, I know it would a lot of administration job to configure,
if PC has software firewall loaded on.

Basically, you are saying at any PC living at the OPT2VIANIC network can turn
off software firewall totally. Because it is cause a lot of problem since you have
pfSense firewall rule guarding the interface, and then you have another
software firewall guarding in Windows interface.

Either put everything off the LAN or change the subnet on the OPT. The way you have it setup now is going to cause problems.

OK I figured it out by enabling manual NAT and natting the bad internal network;

I don't recall having to do this for the same setup with "correct" lan subnets.

Hope this helps,

Did you allow it to auto create your wan rule?  This seems to be common mistake, users change the default to not create that wan rule automatically.  And then never create the rule by hand or create it wrong.

Next common is issue is double nat, and that traffic never gets to pfsense wan to be forwarded on because user doesn't setup the forward or dmz for pfsense wan in the device in front of pfsense doing nat.

I believe both of these are mentioned in the troubleshooting doc, if not I will edit to include ;)

edit:
Both of those are clearly mentioned in items 1 and 8.

Got it… Sorry, I misinterpreted what you were getting at.
That's why I run both as UDP is preferred, but you have that fallback  ;)

If you can access OWA externally and you set up DNS internally for BOTH autodiscover and the hostname of the mailserver (e.g. mail.youdomain.com and autodiscover.yourdomain.com) and pointed them at the private IP and not the public IP then something is wrong with your exchange server settings. Research how to configure autodiscover or ask your questions on a MS forum as keyser suggests.

@pfSensible:

But if they know my IP address and my MAC ID isn't this enough to be able to route the traffic back?

No. If the IP is not theirs, they wouldn't have routes for it from the Internet at-large. It wouldn't trust the IP on the packet more than its own (or its upstream's) routing information (BGP, tables, etc). They couldn't deliver it back to you unless you also had a subnet in common with them (e.g. and IP in the same subnet as one of their gateways) and even then, since it's not one of their IP addresses, they wouldn't route it back to you anyhow.

As fragile as the Internet really is, it's not that fragile, or things would be a lot more broken than they already are…

Basically there is no need to use NAT for webconfigurator, however you can use it to forward access on WAN to LAN interface.
Have you put the appropriate rule on the top of rule set of WAN or LAN, whatever you will use, to ensure no other rule is blocking the packets?

For troubleshooting enable logging of pf rules and also enable logging of firewall default blocks in System Logs settings. So you can see in System Logs which rule is blocking the access.

The hostname isn't properly configured in your Kloxo server. The screenshot you posted tells the probable causes. Lots of references out there that undoubtedly have some solutions.
http://lmgtfy.com/?q=%22domain+is+pointing+to+the+wrong+kloxo+server%22

The default gateway of public asterix server is going to be the ISP gateway. So you will need to add a static route on public asterix server to tell it that 192.168.1.0/24 is reached through pfSense WAN IP 20.20.1.200
Then have pass rule/s on pfSense WAN to allow traffic source 20.20.1.201 destination 192.168.1.n (the server/s you want to allow it to access) port as needed.

Your firewall rule is only allowing TCP. That will mean that DNS requests from clients (UDP) are being blocked. Clients will not be able to resolve DNS. You can probably ping 8.8.8.8, but not ping by name.

I use the WOL tool integrated in pfSense.
Services > Wake On LAN

If applicable you can apply a special user for that and give solely the appropriate permission to him in user manager.

Yep. And for reasons like that, it's easier to keep the 127.0.0.0/8 NAT rule in place by default.