WAN is a failover-group of three conections. Not round-robin, the fastest is tier1, the slowest is tier3.

LAN network is
10.10.10.0/24 where the gateway to WAN is 10.10.10.252 (CARP vIP)

VPN network is
10.10.90.0/24 Clients with an IP from this network don't get a gateway-IP during connection.

Clients from VPN can access the LAN
Without gateway Windows blocks all incoming traffic from VPN-TUN,
so Clients from LAN can't access VPN-Clients (if the windows-firewall is OFF they can, but this is no solution)

As you told me, there is no DHCP. Then - in my case - 10.10.90.1 is the right IP for the VPN-Clients as gateway?
Clients get an IP via VPN, also they get the configured DNS, but no gateway and I can't find where I can manage that.

regards

couldn't setup a simulated leased vpn circuit so i implemented the lab settings on to the production environment after office hours… removed the static route from office1 lan to office2 lan on the office1 pfsense and everything was still working... until i disable the static route from office2 lan to office1 lan on the office2 pfsense. when i return the static route, everything works again (had to connect to one of the office2 terminals via teamviewer).

might have to check out ospf...

thanks!!

Well no, unless you check "Strict User/CN Matching"… Still, much better practice.

It appears that this was an issue with the clients being on the same network as the DEMO lan (the clients have more than one network adapter).  After I moved them to a different network, everything worked as expected.

Thanks for assisting.  This is resolved.

It seems the NAT settings were the culprit. I changed to the new outbound nat hybrid mode, and removed a "catch all" rule I had entered (which I think was a bad idea), and things are working good now.

Nm figured it out. All I had to do was to add the subnets to the local/remote network(s) in the OpenVPN configuration.

I figured it was something like this. I have over 60 sites, but have narrowed it down to geographical areas. I plan on implementing this in three sites first and then breaking the rest up. Most data will still be going to our data canter, so removing the remote LAN is not an option at the data center. I think I can just setup routes or administrative distances.

Thanks for your reply,

Dilster

You seem to have forgotten what type of vpn you are using…

You need rule/s on Firewall->Rules, OpenVPN tab, to allow traffic from source OpenVPN tunnel 192.168.30.0/24 to destination LANnet 192.168.20.0/24 - or for a start put a pass all rule (protocol all source any destination any).

Did you figure this out or find a solution?  I think am trying to figure out the same exact thing but having a hard time figuring it out at this time.

Assuming there is a straight forward setup at each end, you either have a routing, firewall, NAT, DNS or application (phone system) issue.  You've stated that both sides can access each other's resources, so the networking should be in place, but I hate to assume, so we need more details:

Post a network map, so we have a better idea of how things are connected.

Post the server1.conf from server and the client1.conf from the client.

Post a screen shot of the firewall rules from the LAN tab and OpenVPN tab on each end

What kind of phone system is being used and what is it running on?

Are there any blocks in the logs at either end?

@Derelict:

Those look like changes so the VPN clients can get out to the internet (not sure about the WAN_DHCP on the OpenVPN tab).

You asked about being able to get to hosts on LAN, not the internet.

Initially I couldn't ping the LAN or the internet. Somewhere along the way the LAN started working, but the internet held out for a while. While I was able to figure out how I enabled the internet (per the above), I have no idea what I did that got the LAN working. It could have been as simple as rebooting the box (instead of just the OpenVPN service).

Thanks for your help.

In Windows, you should have an "Add a new TAP virtual ethernet adapter" shortcut among your programs list (mine points to "C:\Program Files\TAP-Windows\bin\addtap.bat").
Adding an extra adapter could perhaps be a workaround for you, as the OpenVPN connection only uses one of them, the other one will stay disconnected always, maybe fooling your stupid wireless driver about connection state. It's just a try.

How about pushing a default gateway to the clients so that all the traffic would go through your interface?

Yep I had a similar issue here.

My WAN IP changed (due to a modem reboot), and then I lost control of openvpn via the web interface… restarting produced the following errors :

Mar 16 16:01:00 openvpn[1656]: OpenVPN 2.3.6 amd64-portbld-freebsd10.1 [SSL (OpenSSL)] [LZO] [MH] [IPv6] built on Dec 1 2014 Mar 16 16:01:00 openvpn[1656]: library versions: OpenSSL 1.0.1k-freebsd 8 Jan 2015, LZO 2.08 Mar 16 16:01:00 openvpn[1790]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts Mar 16 16:01:00 openvpn[1790]: Control Channel Authentication: using '/var/etc/openvpn/server1.tls-auth' as a OpenVPN static key file Mar 16 16:01:00 openvpn[1790]: TUN/TAP device ovpns1 exists previously, keep at program end Mar 16 16:01:00 openvpn[1790]: Cannot open TUN/TAP dev /dev/tun1: Device busy (errno=16) Mar 16 16:01:00 openvpn[1790]: Exiting due to fatal error

A quick ssh login, pkill openvpn, then restart via the web gui and everything is working fine again.

^ that
TCP is layer 4, end-to-end between the end-node devices (a client on your LAN and a server out in the big bad internet somewhere). That end-to-end (re)transmission control needs to stay working so it can cope with any packets lost on some other hop from LAN client<->pfSense<->VPN server<->internet-routers…<->final-destination-server - if you somehow stopped passing those real NACKs and/or retransmissions between the end-nodes then they would be in real trouble.
And there is no option on OpenVPN to tell it "use TCP for this OpenVPN hop, but actually do not bother about sending ACKs or checking for packet loss or retransmitting lost packets" - that option is called UDP, use it!

Same question asked and answered here.

Things change and attack methods and vulnerabilities change, but to my limited knowledge, this pretty much covers your question.

http://security.stackexchange.com/questions/73469/tls-authentication-openvpn-mitm-attacks-on-public-wifi