Ah - so like the info a bleach that says do not drink this ;) that wording is already on the wiki doc btw https://doc.pfsense.org/index.php/OpenVPN_Client_Export_Package "If the list is empty, there are likely no users and/or certificates that exist which use the same Certificate Authority as this VPN server. " If you click the little ? mark top right corner of the export package page it takes you there.

You can use up/down scripts: Add to custom server options: script-security 3 system; client-connect /usr/local/sbin/up.sh; client-disconnect /usr/local/sbin/down.sh; up.sh: #!/bin/sh /full/path/to/your/console/email/app down.sh: #!/bin/sh /full/path/to/your/console/email/app mailx example: echo "Client $common_name connected to $HOSTNAME" | mailx -r "your@mail.com" -s "Client $common_name connected to $HOSTNAME from $trusted_ip" -S smtp="your.smtp.com:25" -S smtp-auth=login -S smtp-auth-user="usr@smtp.com" -S smtp-auth-password="password" touser@mail.com > /dev/null OpenVPN vars that you can use: $common_name $HOSTNAME $ifconfig_local $ifconfig_pool_remote_ip $untrusted_ip $trusted_ip $dev

Easy, go to Interfaces Tab, select the Interface you need to spoof, and type in the desired MAC in the "MAC Address" field. Also see this article, you may need to use shellcmd (it's a package you install) to run the interface in promiscuous mode (you should not need to do this with an intel NIC, but it may be necessary with a Realtek or other cheapo NIC): https://doc.pfsense.org/index.php/Interface_Settings#MAC_Spoofing Here's a thread on the topic: https://forum.pfsense.org/index.php?topic=106819.0

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.