The only rule I have is the auto generated one, Allow all from all. I am not using squid as a proxy. However you asking the question made me start thinking in a different direction. I have a content filter in between pfsense and my network. I bet something is happening there. That would explain why it's just http/https. Thanks. If I figure it out I'll update.

So I am at company X, and my company has servers lets call them serverA.companyX.com for example How does 10.0.8.1 as your home DNS know about serverA.companyX.com when it is only resolvable by computers on the companyX network - its is not open to the public NET..  For example the Active Directory servers. While you can hand out multiple dns to your pfsense clients, just because you have multiple dns, depending on what the dns returns when asked for serverA.companyX.com its just going to stop..  And if I ask say the companyX dns for something at home pfsense.localdomain.net - it sure and the hell does not know.. The best solution to this sort of problem is say run bind on your box..  Point to it for dns.. And in it have forwarder for localdomain.net to ask your dns on your home network, and everything else go to your corp dns. That way you can resolve both your company stuff and your home stuff when you have a vpn connection.  It does not have to be bind, could be dnsmasq, tinydns, unbound, anything that can make the call..

@Derelict: I think most of what you need is here: https://forum.pfsense.org/index.php?topic=46984.0 I don't think you need the fix package any more.  That post is a couple years old.  I don't see it listed in available packages. Thanks !! I will try the guide!

Derp.  Thank you.  I don't know how I missed that option during the setup wizard, but I did.  I edited the server entry under OpenVPN for my LDAP server, changed it to Remote Access (SSL/TLS + User Auth), and the client export wizard now shows a client build for the certificate I cut for my test user.  Now I jsut need to install it someplace and verfiy it's all working :D  Thanks a ton!

you need to add the network so the traffic can return Absolutely, you need a return route for the road warrior tunnel network on PFsense02, so the return traffic gets routed down the tunnel….but if you notice, the road warrior tunnel network is 10.0.7.0/24 not 10.123.45.0/24. I'm guessing he was working on multiple documents and posted the wrong subnet by mistake because 10.123.45.0/24 is no where in his diagram. Someone please point it out if it's right in front of my face and I'm missing it, but going strictly off the diagram... I don't see any reason for routing 10.123.45.0/24 down the tunnel.

After some testing, I have installed a new VM acting as a vpn server with pfsense 2.2 beta. pfsense 2.2 has openvpn version 2.3.6 and openssl 1.0.1i by default, therefore it utilizes finally AES-NI feature, which reduces the cpu load by 45% in average, meanwhile I keep the 15mbyte/sec download bandwidth over vpn.

Nope.

While the restricted to IP address would pretty much lock it down..  That sort of thing is really hard to do if this going to be a road warrior sort of connection.  If its for you to connect to your house from work that is another thing. You should never share connection creds or certs, so yeah - if you have multiple users they should all have their own details. +user auth would protect against if the certs and configuration were lost. Yup good thing. Kind of given you would want auth the TLS - that is default I am pretty sure.. Auto gen is fine - unless you already had some keys you wanted to use from before, that sort of thing. 2048bit should be more than enough, but feel free to use 4096 if helps you sleep at night ;) I personally just use BF-CBC 128 bit, it going to be a rare thing that someone would grab your packets and break the encryption..  I don't work for the dod, its my connection from road or at work to the home network.  Want some that is least cpu overhead.  If you have some hardware that can help with the encryption than use the alg that is best suited for that..  Other than I don't think it going to matter all that much.  Again if AES 256 helps you sleep then sure use that. As what your doing with your CA.. Not sure what your asking.. You create a CA in pfsense, you then gen user certs using that CA.  Are you wanting to use some CA outside pfsense and have it gen your user certs?

my fault thx for the help

i thoguht about that at the beginning but since im using nat for both 80 and 443 for my development box i cant test the OpenVPN on it. i turned the SIP ALG back on , but for some reason it is still working. honestly , im clueless, as long as it works, im an happy man.

Will IPsec let you do this?  

Yes, the computer stays in the ordinary LAN with the others - it just has a fixed known IP that makes it easy to match in a rule. create a rule for this special computer IP before the others LAN computers rules Yes If yes, what do you mean by "!LANnet". Is it a special net I have to create? If yes, where in the menus? I mean, in the rule destination select LANnet from the dropdown list, and check the "not" checkbox. You do not want traffic from "special LAN IP" that is going to the pfSense LAN itself to be forced out WAN_GW And "gateway WAN_GW"? Should I create a Gateway somewhere in the menus? In the advanced section of rule definition there is a "Gateway" row - open that up and pick WAN_GW. That will force the matching traffic out WAN.

Thanks jump. Yep, that seems to be it.  I am running an ATOM Dual-Core 1.66GHz D510 CPU, and it can only muster about 7-8MB/sec with compression on the OpenVPN tunnel.  I can easily hit 10-11MB/sec using my Mac laptop (Quad-core i7). Appreciate the reply.

Ok.  My CA expires many years earlier than my user certificates expire.  I'm assuming I'll have to reissue the certificates when my CA expires?

@Derelict: Can you dictate the LAN addressing scheme for the remote sites?  If so, then pick something like 172.26.0.0/16.  Put that in the remote network in your server instance.  That will put a route in pfSense telling it to send all traffic for 172.26.0.0/16 into OpenVPN. Then, in your client-specific overrides do something like this: Site 1: "iroute 172.26.1.0 255.255.255.0" Site 2: "iroute 172.26.2.0 255.255.255.0" Site 3: "iroute 172.26.3.0 255.255.255.0" Site 4: "iroute 172.26.4.0 255.255.255.0" Site 5: "iroute 172.26.5.0 255.255.255.0" iroutes are internal to OpenVPN so when OpenVPN receives traffic from pfSense for 172.26.3.12 it knows to send it out Site 3's tunnel. Doing this allows you to leave the server instance alone when you add/move/change sites (changing the remote networks in the server instance restarts the server).  Changing client specific overrides doesn't. I'm testing it now and it looks like it might be working correctly. I will test a bit more over the week before marking this resolved. Supernetting… it's always a simple answer  :o Thanks for your reply

@Derelict: Please see: https://forum.pfsense.org/index.php?topic=82732.msg473856#msg473856 Derelict, that was exactly what I needed. I knew I was over analyzing the problem. :) I setup the push routes and tested and it's working perfectly. My only issue right now is the huge range of ip networks AWS uses and it's always changing, but that's a different issue altogether. =) Thanks for the clarification!