In the packet capture you can see the echo request leaving the Client LAN interface addressed to 192.168.0.201 and nothing coming back. The problem is somewhere outside of pfSense. Yes, pfSense has to be the gateway for the target device or you need to add a route on that host for the far side of the VPN tunnel with a gateway that is pfSense or the replies will be sent to the wrong place. Alternately you can place an outbound NAT rule on the client LAN interface so traffic sourced from the remote VPN network is NATted to the interface address there. Then replies will be same-subnet so the route will not be necessary.

Services watchdog will not do anything if the OpenVPN process continues to run. If the OpenVPN connection continues to run and the internal (to OpenVPN) keepalive pings continue to respond, but the OpenVPN provider stops passing actual traffic, I can't think of a built-in way to restart that tunnel. You might consider getting another VPN provider - or trying another site on that one. It looks broken.

After posting that screenshot I noticed that in all my fiddling around I was missing a NAT rule. Seems to be working now, whatsmyip.net is getting a different address to my WAN address. Thanks

Maybe it's why nobody can understand what you intend to achieve. What does in mean "how to configure an OpenVPN Client on only OPT1 interface"?. Only devices connected to OPT1 should use the vpn? There are thousands of tutorials about setting up a vpn client in the web, text as well as YT. That should be straight forward.

Here are various iperf/speedtest results… Summaries in bold.: -Inside VPN (TCP): iperf: 1.48 Mbits/sec http://i.imgur.com/v1CHGZM.png -Inside VPN (UDP): iperf: 1.45 Mbits/sec http://i.imgur.com/aJ2DF1O.png -Client to Outside Internet: iperf: 3.72 Mbits/sec http://i.imgur.com/MwlC8wX.png -Client to Outside Internet (Speedtest.net): Speedtest: 86.61/86.92 Mbps http://i.imgur.com/qDqOlel.png -Inside server network to Outside Internet: iperf: 23.3 Mbits/sec http://i.imgur.com/4v1YOyI.png -Inside server network to Outside internet (speedtest.net): Speedtest: 56.43/63.89 Mbps http://i.imgur.com/RRF2oKv.png So looks like the VPN is running at the speed allowed by my client ISP minus 60% overhead. What's more interesting is the Server ISP (50/50 Verizon FiOS) is showing only 20Mbits/s. Not sure what to make of that information, considering speedtest shows 50Mbps. Not sure if this conclusion is correct, but it looks to be traffic shaping by the client-side ISP. I'm going to fiddle around to try and reduce the overhead required. Need to better understand the impact of MTU Set up servers inside the client side network to better assess internal throughput. Experiment more with 128bit encryption

Are you trying to reach the client end point device or a network behind the client? For accessing the client device you will need to open up its firewall. If you want to access a network behind the client you will need vpn routes in addition. Is it a SSL/TLS openvpn or a shared key?

Does that mean, you're running a vpn access server + a vpn client for site-to-site connection to A on site B server?

Another point to check here is if the local and the remote networks overlaps.

You could prevent a device in your network to interrogate an unwanted DNS, adding two rules like these in the Firewall LAN tab. In your case the first rule should contain as destination an alias with the DNS addresses you want to authorize.  

Can you help me ? @sinanc: Hi, I am using PFSense version 2.3.2-RELEASE-p1 1 wired metro ethernet internet connected and 4 multi ip address. I use open ssl vpn service from my main wan ip address which is defined as virtural ip. I want to set up an open ssl vpn service from a different main virtual ip address. The open ssl vpn service I installed will not be able to connect to the local network, but when the client connects to this open ssl vpn, I want to get the open ssl vpn ip address, which is my second definition of the internet out ip address. Sample diagram, Main wan ip 192.168.1.1 open ssl vpn service has local network access client exit ip address 192.168.1.1 Multi wan ip 192.168.1.2 open ssl vpn service local network access disabled client exit ip address 192.168.1.2 I tried to make adjustments, but it did not work. Client vpn wan could not get out ip address because I did not select Tunnel settings / Redirect Gateway in open ssl vpn settings. Can you help me ? Regards.

Many thanks Duren :D I will try that advanced auth entry.

The routing was correct. The packets were being sent out the correct interface. Rebooting other devices must have cleared something elsewhere. Glad you got it sorted out.

I assign an addtional interface (ovpnc1 in this case). Activated this (no ip nothing just activated) Then i set an static route to 192.168.50.0/24 on the gatway of this interface.(this was the way of doing this, as i know since years) But my question is, the text in newer Version state like this is not needed any more.

You were right. After dealing with the datacenter's support, we found I could enable IP spoofing on the LAN interface for the pfSense VM and after allowing that, it works fine without NAT.

@Soyokaze: Test with same hosts and ports on your own PC (not from pfsense), Test from both PC and pfsense with different hosts/ports. Did this and was the same but it did give me an idea and found what was the issue. A power surge took one of my ports out on my switch and was stuck in 10MB half duplex which was causing the whole network to go to it. Repalced the switch and good to go. Thank you!

Then I would suggest you put that in as a feature request on redmine or possible the package section.

The firewall can't easily act as both a destination (routing) and a bridge. You would have to manually set a route on each system in your local network, pointing the VPN subnet to the firewall's IP address. When a VPN client tries to contact a server, the server's reply would be going to its default gateway (on the WAN side of the firewall) and not back to the firewall itself. It may also be possible to put a route on the default gateway to point the VPN subnet back to the firewall's IP address, but that would be rather messy. It is nearly always better to NOT bridge, but to do routing. If your ISP provides you with two blocks (one for WAN interconnect, second block routed to the firewall in the first block) then you can do away with bridging and use a proper routed setup instead.

I was able to figure this out. The problem was caused by "Authenticated Users" no longer being included in the Pre-Windows 2000 Compatible access built in security group. This group normally provides read rights to all AD Objects. Previous and existing domain admins were automatically being assigned some of these read permissions. Fixed by giving the pfsense LDAP Active Directory account read access to all users.