You can do this in System > Routing > Routes. 
Add a rule for the site you want to go to over the WAN by getting the correct IP Address using the below method:

Get a Websites IP Addresses to exclude from VPN using the Terminal:
host domain name      [to obtain IP Address]
whois ip address
use the CIDR ip address range (69.53.224.0/19)        [This is the IP I have set for Netflix]

On the rule you create, set the Gateway to WAN.

Thanks, heper!.  Your post helped me a lot. I had the same suspicion , but got scared from the new 2.2 advanced routing screen :-)

For anyone in the future who might have the same problem.

On Pfsense 2.2, go to NAT -> Outbound NAT.

Switch to Hybrid NAT.

Add entry on WAN(most likely) for NAT. Source should be your Openvpn LAN of the remote site.  Please have in mind that in my case there was NO NAT(on purpose)  between openvpn remote  LAN and tunnel net. In case you have such NAT, you might need to change advanced NAT rule, source to be the tunnel net.

If I understand your description, your setup is something like:

Started with:

LAN_B–-------[SiteB Client1]-WAN->(OVPN 10.76.0.8/30)<-WAN-[SiteA Server1]–-------LAN_A
(192.168.42.0/24)                                                                                                          (192.168.40.0/24)

Then you added a new OVPN server on SiteA to give you:

LAN_B---------[SiteB Client2]-WAN->(OVPN 10.76.0.8/30)<-WAN-[SiteA Server1]–-------LAN_A
(192.168.42.0/24)                                                                          /      |                        (192.168.40.0/24)
                                                                                                      /      |
          LAN_C--------[Other Client2]–-------(OVPN 10.76.0.44/30)--/      [SiteA Server2]
(192.168.0.0/24)

So (B) <-> (A) can communicate fine, but (C) <-> (A) sees only the tunnel address 10.76.0.45&46?

This is usually a routing problem in the OpenVPN config.
What type of server did you create for Server2 (SSL/TLS, Shared Key, Remote)?

To accomplish what you're asking would involve configuring a bridged solution.  But the question is what are you trying to overcome by implementing a bridged VPN solution?  Routed is "better" in almost every case, so I'm curious as to why you're thinking about implementing a bridged solution.

The only reason to go bridged is if your clients need to communicate with an application that relies on broadcasts.

Yes, the DNS server originates from another subnet than the configured local network.
What do you mean with /32?

Since your DNS server is in a different subnet, you will have to enter their IP's in the DNS section and push a route to that network, which is what viragomann described.  The /32 is CIDR notation and has to do with routing.  In this case, if your DNS server was on 192.168.100.10/24, instead of pushing a route to the entire network (i.e. 192.168.100.0/24), you could just push a route to the host by entering 192.168.100.10/32, which would isolate access to the DNS server only instead of the entire network it sits on.

Is the ip only not sufficient?

For the DNS servers, yes, but not for the "IPv4 Local Network/s" section or any other network portion of the config.

I missed iroute in client overrides :)

From official documentations:
For a site-to-site SSL/TLS server using IPv4, the IPv4 Tunnel Network size can alter how the server behaves. If x.x.x.x/30 is entered for the IPv4 Tunnel Network then the server will use a peer-to-peer mode much like Shared Key operates: It can only have one client, does not require client-specific overrides or iroutes, but also cannot push routes or settings to clients. If an IPv4 Tunnel Network larger than that is used, such as x.x.x.x/24, the server will accept multiple clients and can push settings, but does require iroutes.

Yup.  That's why I just took it at face value and didn't try to interpret.

That's the first time Ive read that document I have to admit.

On the outbound NAT page notice that the address they show is the "Tunnel Network" and not one of your LAN addresses.  It might be easier for them to show a totally differen't subnet as their tunnel network in that document to help people not jump to the wrong conclusion as I did when I first skimmed over that.  But read slowly and you will catch it.

I use a majority of addresses in the 172.x.x.x range and all my tunnel networks are 10.10.1.x/30  I just use the next /30 as I add vpn's.

If you don't intend on routing all your internet traffic through one site or the other just skip the last instruction under Advanced Configuration.

hi,
I have the same problem, there any solution?

Thanks

is there on the Server side a AD/DC in usage? Did you create there then User accounts then?

Yes, but if this is the problem I expect that Windows ask me username and password when I try to connect to the network drive (like happen when I use the IP address).

OpenVPN traffic is going out WAN, comrade.

I've changed to "keepalive 10 30".
I've changed the DNS.
We'll see.
Thanks

The config looks ok.  So, there's a couple things:

Make sure there's a route to 10.94.10.0/24 in your client's routing table upon connection.  If not, verify that you're running the OpenVPN client as admin.

It looks like you're double NAT'ing.  If you have access to the modem or edge device, the easiest fix is to put your modem in to bridge mode, so PFsense gets a public IP and everything will start working.  Otherwise, you may need to add a route to the edge device that points the OpenVPN tunnel network towards PFsense.

It was route on host i LAN I added route to 192.168.34.0/24 and everything is ok. Thank you for answer.

@viragomann:

If you can not change config at B site you can get access if you do NAT at A.

To do so you have to assign an interface to the VPN client and to VPN server, if you haven't done allready.
In site A's client settings add the remote subnet 192.168.88.0/24 to "IPv4 Remote Network/s" and in server settings add it to "IPv4 Local Network/s".
Go to outbound NAT. If it is set to "automatic rule generation", select hybrid or manual and hit save.
Add a new rule, select your VPN client interface and leave all the other setting at their defaults, enter a description and save it.

Now the source addresses of packets get translated to the site A's vpn client address when packets leave pfSense on the vpn interface, in consequence now responses from B are routed back to site A.

This worked! Thanks

I'm inclined to agree with you - looking at OpenVPN PID files, quite a few of them had really high PID numbers, into the billions!

I can run;
killall openvpn ; rm -f /var/run/openvpn_*

Then when the services are restarted, they all work fine until the next service crash or config reload.

Also, (probably because of this issue), if I have the faulting services in Service Watchdog, I eventually end up having to reboot the routers (PID exhaustion? Is that still a thing these days?).

Anyhow, probably a week from today, I'll be able to get us a few dates that we'll be quiet enough to not suffer from having to reboot systems, etc.