@cmb:

Yes, it's best to leave the servers running always.

That brings me a problem, when i'm connected throuh openvpn i can't access pfsense2, i guess it's because pfsense2 also has an openvpn interface with the same IP address, correct?

Any away to workaround this behaviour?

ok,
I had to give it a try again and accidentally  I found where my mistake was…  :-[

I just ported the stack from linux to pfsense, without having in mind possible incompatibilities in pam control flags.
So "[success=1 default=ignore]" is not acceptable in pfsense and that caused my errors…

I should close this...
thanx anyway

yeah, sorry misread … need to stop responding to things before having a couple of gallons of coffee ;)

@divsys:

@heper:

your "tunnel network" is the same as one of your "remote networks"

this is most likely the cause of this error. either change the tunnel network, or remove the remote-network.

Er, I think you misread.  The OP has tunnel network:

OpenVPN IP: 10.1.0.0/24

While the remote nets are:

LAN1 = 10.0.0.0/24
LAN2 = 10.0.1.0/24

No conflicts there, he's using 10.0.0.x,10.0.1.x,and 10.1.0.x.

tun/tap are fundamently different. personally i'd allways use tun if you are not bridging. Routing over tap is just causing yourself more trouble then needed.
tun will almost allways result in better throughput.

quote from openvpn website:

Now lets see benefits and drawbacks of TAP vs TUN.

TAP benefits:

behaves like a real network adapter (except it is a virtual network adapter)
    can transport any network protocols (IPv4, IPv6, Netalk, IPX, etc, etc)
    Works in layer 2, meaning Ethernet frames are passed over the VPN tunnel
    Can be used in bridges

TAP drawbacks

causes much more broadcast overhead on the VPN tunnel
    adds the overhead of Ethernet headers on all packets transported over the VPN tunnel
    scales poorly

TUN benefits:

A lower traffic overhead, transports only traffic which is destined for the VPN client
    Transports only layer 3 IP packets

TUN drawbacks:

Broadcast traffic is not normally transported
    Can only transport IPv4 (OpenVPN 2.3 adds IPv6)
    Cannot be used in bridges

Solution?

Don't have a newb setup the VMware host server.  :-[  The problem was that there wasn't a gateway defined on the host server.

It ended up not being an OpenVPN/pfSense issue.

Had the same problem with mine before my box crashed (now can't get it back working).
Change the first firewall rule from DEFAULT GATEWAY to the GW-WAN…......that will get ALL the traffic off the Tunnel, but the tunnel will stay up and working......then peck, peck your way through the other.

Now as to the rest, if I can get mine back up and working I believe that we will have to set up some kind of routes for the VPN and burn a firewall rule in for EACH device you want out the tunnel (by IP, Name, etc)

P.S. Backup you config.xml file with your working configuration BEFORE you start tweaking!!! That way if you break it all....you can restore the working configuration....trust me I know.

Haven't worked on mine lately...too much Holiday.....

Don't know about you robina80, but if you can get the tunnel up and running OpenVPN to your provider, then every device connecting with your PFsense Box will go out through the tunnel, as I understand it the OpenVPN client is by default bound to the WAN…..........

Basically the way mine worked...(before the GREAT CRASH....and Decent Recovery) is that ANY device present on my Network that went to the Internet thru my Box, Went thru the tunnel.

In my case I need to get mine back up and configured to EXCLUDE every device except a select few from going out the tunnel.........If it wasn't for the other half's soap's on Hulu and CBS I'd LOVE for everything to go out the tunnel............Women!!!!

I know that doesn't do you any good when away from home....
You can set up IPSec, L2TP and PPTP like divsys said....buuuuttt I don't think you can use them all at Once.

Well, considering that the link in that post goes to a dead Drupal site, I'd say that we're probably all better off.

Getting something like this going is probably a better long-term solution anyway.

https://github.com/evgeny-gridasov/openvpn-otp

Update … fixed, by altering the OpenVPN client config to

fast-io; persist-key;replay-persist cur-replay-protection.cache; remote-random; pull; verb 5; key-direction 1;route-method exe; route-delay 2;tun-mtu 1500;fragment 1300;mssfix 1450;
persist-tun;keepalive 10 120;

keepalive 10 120 was the actual differentiator that made it work.

But if I disable the override my client gets an ipv6 address and everything is golden but I would like to choose the ip of my clients.

If you are running Android 4.4.x you will encounter a bug related to the tun0 interface.

After setting up the OpenVPN connection you are able to ping6 the Android 4.4.x device from your server, but you cannot ping6 the server or other IPv6 targets from your Android 4.4 device. This bug doesn't occur in Android 4.3 (And earlier?) and occurs in all Android 4.4.x versions including 4.4.2. There is no known workaround for this issue except hoping on a fix in Android 4.4.3.

You have got a new WAN gateway and pfSense will have reconfigured outbound NAT. Maybe this has messed up your outbound NAT settings for VPN connections.

I thought I'd best post an update:

After turning off the gateway monitoring I monitored the VPN connectivity for around 48 hours, it dropped maybe 3 packets the whole time but the VPN stayed connected.

Thanks.

Now moving on to the next challenge :)
I thought I was in the clear as I can ping both ways and access standard items both ways so I am pretty confident that the setup so far is on the right track …but I think I am missing something.

I need to connect to a specific port on the vpn network from the internal network. When I try it netstat on the client side is actually reporting it as established but no data will flow. When looking closely I can see that netstat reports the connection done between the client and the openVPN interface and not the source as I expected. See screenshot enclosed .. the source is 10.0.0.18

Is this the root of my problem and if so how do I make sure the communication flows back?