I've got file sharing working. For those of you interested in this setup, what I did was start a WINS server on my DC computer in the 10.0.1.x network. Then on the outside firewall I added the WINS server IP, DNS server IP, domain name, and domain search list under services–>dhcp server-->LAN. After doing this I was able to resolve internal websites, and access network shares from a client computer on the 192.168.15.x network.

Now that the test setup is working, I'll try adding a few more client "sites" to the mix and see what happens if I expand the setup a bit.

This guide is based on 1.2.3
In 1.2.3 there wasn't an option to specify in NAT rules a source.
What the guide is refering to, are the "external" and "internal" port.

In relation to the screenshot you posted:
The "Dest. ports" and "NAT ports" should be 1195, but the "Src. ports" should be any.

The other side of the site-to-site knows nothing about the roadwarrior subnet.
–>you need a static route to make the roadwarriors known.

I don't think you can use TAP in 2.0…. http://doc.pfsense.org/index.php/OpenVPN_Bridging

First of all, find out the IP address(es) that the hostname in question resolves to.

Then on pfSense1 create a static route for those IP addresses that routes through the OpenVPN tunnel. You'll need to ensure that both pfSense hosts know how to route to the LAN on the other side.

It works after changing the MTU only for the wan interface facing the proxy to 1200, 1300 won't work. Weird thing…

Yes, that's it! All the Certificates were corrupt… strange.  ???
But now with the new certificate the Client Export Tool works perfect.

Thank you very much...  :)

It should be "good enough" in most cases, though you don't get the extra security of the certificates.

The User Auth only still uses a tls key in addition to user auth, so it's still secure.

I think there is an open ticket somewhere to open that up so that it can be used for other auth methods. It would just require making the certs in the cert manager (or elsewhere) manually instead of them being tied directly to user accounts as they are with Local auth.

Yeah there have been some UDP issues in the past where the return traffic will use the default gateway regardless of the interface used for connecting when using 'any' interface, though I haven't tried that lately on 2.0 so I'm not sure if that's really an issue these days.

Binding to LAN and forwarding ports lets it take advantage of pf's reply-to directive which ensures the traffic goes back out the WAN it came in on.

I've just tested using a 3G modem and works perfectly, I can reach any service available to LAN users form OpenVPN Users.

Thanks for your help

Please start a new thread for a new issue, so it's easier for others to find and contribute.

That worked perfectly!

I just tested the setup you suggested with 3 test users and had filtering working exactly the way I want.

Thanks for the help!

It can be done, but it involves using client bridging and adding custom configs to the server.

Stick with the routed solution, it's more efficient and it looks like they are eliminating bridging from 2.0 anyway.

What eventually fixed it for me was swapping the openVPN protocol from UDP to TCP. Up to this day this still makes NO sense to me whatsoever as it all worked though UDP as long as I did't leave the LAN. Accessing remote websites as an openVPN client jsut didnt work using the UDP protocol.

I made a small post on my blog explaining the steps I took to get it working. URL : http://henri.kuipersite.nl/2011/02/25/the-alix-project-part-2/

I hope this will give you enough info to get it working for you too. If not (or if it does) let me know via a reply here and/or a little note at the blog :)

Happy VPNing

no takers?

-Rich