I see - Appreciate the info!

When defining the tunnel, make sure to put all the relevant networks at each end into the Local Network/s and Remote Network/s boxes on the webGUI. Then routes across the tunnel will appear when the tunnel comes up.
Put pass rules on each end of the tunnel to allow the incoming traffic from the other end.
Put pass rules on local subnets firewall rules to pass the traffic for the other end without putting it to any gateway or gateway group. That way this internal private network traffic will be handed directly to the ordinary routing table.

(If you have multi-WAN and thus have rules that feed lots of public internet traffic into varioues gateways or gateway groups, then the pass rules for the internal OpenVPN traffic need to come before all that - you do not want to accidentally push your internal traffic out some gateway to the public internet.)

My problem is this.

I can ssh to all clients on my network and vpn just fine. But when I try to see their share folders I can not. I have done some reading and I'm starting to think it's because my VPNserver is not sending a gateway so the network stays unidentified

jdsimonds, I believe it's already been said in one way or another, but everything is working as excepted.  You have configured a routed tunnel and you can access everything via IP.  However, broadcast traffic will not traverse a routed tunnel.  That is why you are unable to see shares, browse for computers, and access resources by name the way you are used to.  You will need to configure a bridged tunnel for that.

Also, if your main concern is accessing shares and resources by name, just configure a DNS server and push it out to your clients.

A bridged tunnel is less efficient and doesn't scale well.  Typically the only reason to go bridged is if you are running an application that is dependent on broadcast traffic.

IMO, you'll be much happier keeping your routed tunnel and fixing your name resolution issue via DNS instead of bridging and replicating all your Broadcast (NETBIOS,etc) traffic over WAN links.

Success!  I fixed the POS VLAN IP address, rebooted both boxes, and whole POS system now works.  Performance is a new issue, though.  A slight one or two second lag occurs sometimes at the client site POS terminals, between button presses and screen refresh.  It might be due to the TAP or the ~800 kbps upload limit at both sites.  This ain't over yet, but it works for now.  Thanks dotdash.

When the export links don't show up it's usually a certificate mismatch somewhere.  Like the user certificates aren't created under the same CA the OpenVPN server instance is set to use…

NOTE: If you expect to see a certain client in the list but it is not there, it is usually due to a CA mismatch between the OpenVPN server instance and the client certificates found in the User Manager.

Paid OpenVPN servers usually push you a default route.  If you want to pick and choose what traffic you send over ovpnc3, add route-nopull; to its configuration then use policy routing to send select traffic over it.

Also I'm not sure what we're looking at.  It looks like we're looking at a pfSense with a client that is getting a default route from it's VPN server but it also has a server defined.  Pushing a default route from that server shouldn't effect the default route on that pfSense but on its clients connected to the defined server.

You might need to draw a diagram.

PPTP is faster and easy but less secure and for some reason it is not working on some broadband device users here, maybe because it uses some shared IP.

L2TP is good but giving me a hard time to it set properly, IPSec works well too particular on site-to-site using tunnel, but using client mode like openvpn I heard that its not working on some device/OS.

I think my plan is not possible to work for now after your interesting feedback regarding on my concern.

Putting my external server behind pfsense and use Virtual IP to solve this while finding some way to work it.

Thanks again Derelict

then you could create a static route on the box your trying to get to, so that it knows to talk to pfsense when talked to from a openvpn client.  Need to create a route for your vpn clients network pointing to the pfsense lan ip.

Other way you could do it is nat it pfsense, so that vpn clients look like they are the pfsense lan IP - but this is bit more complicated.

The correct solution though is to have pfsense be the endpoint of both of these connections - or just get rid of one of the connections, etc.

I added to site to site VPN on client side: Remote Networks: 192.168.0.0/24

Now it looks like everything it's okay.

@Phurious:

I have PIA setup on my pfSense 2.15 box.  What part is failing for you?  If you got to Status –-> OpenVPN what does it say for your PIA client?  Have you checked the OpenVPN logs for an error?

Which method did you use? Were there any additional steps that you needed to take? Are there any services such as snort or pfblocker that could cause problems?

UPDATE: We have success!! For some reason when I was adding the PIAVPN interface the Network Port wasn't saving as ovpn1 () but reverting back to something else. This time I did all the steps and then went through everything again et voila! Thanks to all that helped.

Hmm - how to describe it.

I want pfSense to somehow direct ALL Internet traffic to the OpenVPN.

It is essentially SITE-TO-SITE, but the OpenVPN Access Server is not pfSense. It is literally a OpenVPN Access Server.

The LAN host will already be connected to OpenVPN Access Server (my dedicated server at a datacenter) through pfSense.

ALL 'LAN' hosts will use VPN Server 1 (dedicated server at a datacenter).

ALL hosts on the LAN will use the VPN. So then I don't need to go to each individual host and install the OpenVPN client.

I want to utilize my VPN without installing a client on each host.
:)

That all looks OK. The only potential issue I can see is that the local LAN behind the server is 192.168.1.0/24. If the place the client is connecting from is also 192.168.1.0/24 (or includes that), then the client will try to talk locally to 192.168.1.0/24 when it should be sending that traffic across the OpenVPN link.
If that is an issue, then, if you can, try connecting from somewhere with different private address space and see if it works.
In the long term, it will pay to change the LAN subnet behind the OpenVPN server to be some different private address space - http://en.wikipedia.org/wiki/Private_network#Private_IPv4_address_spaces - picking a "random" chunk of 172.16.0.0/12 is likely to avoid clashes with the local coffee shop WiFi.

I was successful editing using the GUI.

Unfortunately, the OpenVPN windows client can't parse an IPv6 address and can't resolve a host with only an AAAA record.

Fri Nov 14 19:27:33 2014 RESOLVE: Cannot resolve host address: xxx.xxx.duia.us: The requested name is valid, but no data of the requested type was found.
Fri Nov 14 19:27:38 2014 RESOLVE: Cannot resolve host address: xxx.xxx..duia.us: The requested name is valid, but no data of the requested type was found.

Off to the OpenVPN forum…

Do a quick search of your config file for "192.168.1" - that will quickly show where are the other references to things in 192.168.1.0/24
And of course you have to change any clients with hard-coded IP addresses (maybe some Windows servers, a managed switch, an AP or 2, a print server lying around your LAN…)

I had this same problem (and more than a year later). The solution I found was to generate a new bundle using the OpenVPN Client Export Utility package, and switching the "Verify Server CN" setting to "Automatic - Use verify-x509-name", since using tls-remote is now deprecated. The resulting .visc bundle worked perfectly. This was on the latest version of pfSense (2.1.5), so YMMV if you're running an older version.