Aha… Figured it out from: http://doc.pfsense.org/Create-OpenVPN-client-to-TUVPNcom.pdf

I needed to create an extra interface and gateway. All seems to work OK now...

A good place to start is to understand how tunnel networks work. http://openvpn.net/index.php/open-source/faq/75-general/293-what-is-the-principle-behind-openvpn-tunnels.html

The rules on an interface tab apply to traffic coming IN on that interface. The first packet when a "connection/flow/session" is first started is checked by the rules, then if it is permitted, a firewall flow/state is added, and subsequent packets in both directions that match the flow/state are allowed.
Thus, to get out from LAN (to the internet…) a suitable pass rule is needed on LAN. For a connect coming from a client on the other end of an OpenVPN link, a rule is needed on OpenVPN to allow the incoming connect. Once the flow is established, the traffic in both directions for that flow "flows":)
That might be enough to give you the concept and you will be able to apply it in practice.

Thank you Phil for all your help.  I finally got it up and running with your help and Jim's help.  Once I got the OPTn set to openvpn I had to set outbound nat on SITE A for SITE B to get out to public.

All seems to be working good so far.    Now I will work on getting NAT working for the servers in SITE B through SITE A.

@jimp:

@CuriousG:

Edit2: Site C will not always be up, will this affect communication between site A and B?

Avoid using "edit" to ask questions. It does not notify that the post was updated the same way a reply does.

If C is just another client, it won't affect anything between And B.

If A were down, then B could not reach C, but that is the only failure that would be a problem.

Thanks.  It makes perfect sense if A was down since it is the "server".  Only reason I asked is I got a call today that they weren't able to reach A from B but since this user is a handful in the first place I didn't know what to think when I activated site C and everything was fine.

Hey, I have been trying to use your patch and can't work out what I'm doing wrong. I applied the patch OK and created a new entry in 'System: Authentication Servers' then configured OpenVPN server to uses it. Any help would be great

The System: Authentication Servers entry:

System: Authentication Servers
Descriptive name OpenVPNUsers
Type LDAP

LDAP Server Settings
–-----------------------------------------------------
Hostname or IP address 10.10.10.10
Port value 389
Transport TCP
Peer Certificate Authority internal-ca
Protocol version 3
Search scope
Level:  Entire Subtree
Base DN:  DC=domain,DC=com,DC=au
Authentication containers
Containers:  CN=OpenVPN Users,OU=Users,DC=domain,DC=com,DC=au

Bind credentials
User DN:  readonlyuser
Password:  password
User naming attribute samAccountName
Group naming attribute cn
Group member attribute memberOf

OpenVPN Log:

Jun 6 15:51:24 openvpn[45763]: 49.176.33.77:19534 [] Peer Connection Initiated with [AF_INET]49.176.33.77:19534
Jun 6 15:53:55 openvpn[45763]: 49.176.33.77:19534 Re-using SSL/TLS context
Jun 6 15:53:55 openvpn[45763]: 49.176.33.77:19534 LZO compression initialized
Jun 6 15:53:58 openvpn: : Now Searching for janedoe in directory.
Jun 6 15:53:58 openvpn: : The container string contains at least one group, we need to find user DN now
Jun 6 15:53:58 openvpn: : User found
Jun 6 15:53:58 openvpn: : Now Searching in server OpenVPNUsers, container CN=TechNet OpenVPN Users,OU=Users with filter (samaccountname=janedoe).
Jun 6 15:53:58 openvpn: : Search resulted in error: Success
Jun 6 15:53:58 openvpn: : ERROR! Either LDAP search failed, or multiple users were found.
Jun 6 15:53:58 openvpn: user janedoe could not authenticate.
Jun 6 15:53:58 openvpn[45763]: 49.176.33.77:19534 WARNING: Failed running command (–auth-user-pass-verify): external program exited with error status: 255
Jun 6 15:53:58 openvpn[45763]: 49.176.33.77:19534 TLS Auth Error: Auth Username/Password verification failed for peer

Well, I figured out half of my issue…

In the OpenVPN configuration, I mistakenly assumed that leaving the "Concurrent connections" field blank would default to unlimited, but once I plugged an arbitrary positive integer in there, VOILA!  My Tunnelblick client on the Mac can now fully establish a connection.

I still can't get the Windows machine to connect.  I originally installed the client, the imported the configuration from the client export package.  I think I'm going to try and use the Windows Installer export instead and see if that fixes the issue.

Yes, so long as a route is pushed for the other tunnel network.

e.g. the UDP VPN pushes a route to the client's for the TCP VPN tunnel network, and vice versa.

Something interesting is going on in DNS land, is evidently part of my problem.

WAN is, unfortunately, dynamic. Have had a DynDNS.org domain since it was free, and pfsense is (supposedly) configured to update it, and reports it as being up to date (green.) However dyndns's own nameservers reported a different address. This may be some misguided part of their transformation to "notfree." Doesn't actually make me want to pay them, for some reason. Does not appear to be a "caching" problem. Appears to be a "reported up to date, but not up to date" problem. I just corrected it by going straight into dyn.com. That was after checking the username setting and re-pasting the password into pfsense - same username and password pasted into DYN worked, so those are right.

Got a quick subdomain over at FreeDNS (afraid.org), had to make a guess at what the "Auth Code" was, popped that in and appear to have pfsense ACTUALLY updating it to the correct address, so a config exported with that address actually connects somewhat reliably. So far. Many twisty little passages, all alike, indeed.

found the options myself :)
but thanx for all the help! :)

@tbaror:

Ok,
I think the mystery solved , but still not works :( , i discovered next hop right after external fw leg is 192.168.0.254 so this is why there is no  routing to 192.168.0.0/24
but what more mysterious is when i do tracroute from firewall its go trough vpn tunnel  ,but not the case from lan client side
Any idea

Thanks

IMHO, when you ping/traceroute from a LAN client, the packet goes first to your other gateway. That other gateway knows about 192.168.0.0/24 attached to (or close to) it. So it sends it there.
When you ping/traceroute from pfSense, it knows a route to 192.168.0.0/16 across the OpenVPN, so sends it across the OpenVPN.

I am finding more and more, rule #1 of designing a private IPv4 network is, never use 192.168.[0-n].0 addresses (where "n" is maybe up to 10 or 20). Then you avoid conflicts with all the default private networks that get in your way when your network map expands.
I pick a "random" 10.n.0.0/16 and make /24s out of that - e.g. 10.73.0.0/24 10.73.1.0/24 …
IPv6 is much better, with a large chunk of "private" address space to randomly pick from.

More port forward…


Ok, after several hours of fiddling around I have sort of gotten it to work. Its a bit strange but after turn on comp-lzo in the advanced config it does seems to now work, ie if i go to whatsmyip.org it now shows as the strongvpn.

It does seem to be quite slow and is constantly dropping…so this will require more work I feel but at least it is now working..

I hope this will help others who have the same problem.

Yes, the wizard should create some decent rules to let traffic through. Traffic from the Windoes client should have a source IP in the tunnel network, so your extra rule should be a good thing. Post a screenshot of the rules you have on OpenVPN now.

Itried switching to tap but get this error:

openvpn[5474]: WARNING: Since you are using –dev tap, the second argument to --ifconfig must be a netmask, for example something like 255.255.255.0. (silence this warning with --ifconfig-nowarn)

Sorry for the late reply.  I have been bogged down with work.

So here are my answers:

a) What is the server end? (another pfSense, an OpenVPN provider…)

OpenVPN provider

b) How do you specify the server end? (a DNS name, a static IP address…)

DNS name

c) What sort of failures do you see? (is it trying to reconnect every minute, but not succeeding, or has the OpenVPN client process died completely… - OpenVN logs)

openvpn[12214]: RESOLVE: Cannot resolve host address:

d) OpenVPN client conf file

[color] <openvpn><openvpn-client><vpnid>1</vpnid> <protocol>UDP</protocol> <dev_mode>tun</dev_mode> <ipaddr><interface>wan</interface> <local_port><server_addr>vpn.myvpnprovider.com</server_addr> <server_port>1194</server_port> <resolve_retry><proxy_addr><proxy_port><proxy_authtype>none</proxy_authtype> <proxy_user><proxy_passwd><mode>p2p_tls</mode> <custom_options>auth-user-pass /etc/openvpn-passwd.txt;persist-tun;keepalive 10 60;</custom_options> <caref>5186a2372a50b</caref> <certref>5186a29ecfa1d</certref> <crypto>BF-CBC</crypto> <engine>none</engine> <tunnel_network><remote_network><use_shaper><compression>yes</compression> <passtos></passtos></use_shaper></remote_network></tunnel_network></proxy_passwd></proxy_user></proxy_port></proxy_addr></resolve_retry></local_port></ipaddr></openvpn-client> [/color]</openvpn>

e) What type of physical internet connection do you have? and do you see any packet loss (e.g. on gateway monitor)?

ADSL2 and no packet loss

f) Anything else you think might be interesting about your setup.

I have an interface setup as VPN and the routes setup accordingly.  Also I am using NAT to pass all LAN traffic through the VPN interface

@Linuxdump:

Thanks ! But I already tried this no use still the same. I can see that I am missing something very small which I am unable to figure out.
What could be the reason. Firewall rules are automatically created by the pfsense oprn vpn configuration wizard.

Help me to resolve this issue!

two additional things,
1. if you configured the VPN server and exported vpn client , and right after it made small change to vpn server like for example  added

Compress tunnel packets using the LZO algorithm.

you either make the change in the vpn client to adjust it or reexport it again to the user.
2. If your clients are win7 , make sure they are right click when they execute Openvpn client

run as administrator

other wisw they want be able to push routes