So…  Apparently I'm an idiot, and when I downloaded the config, I downloaded the iOS version, and never realized.  I re-downloaded the ANDROID config, and it worked first shot. Sorry for the trouble, but I was starting to go crazy wondering what I could be doing wrong. I'm a m0n0wall convert and I'm really loving psSense!!  I'm running it on a little VIA C7 1ghz fanless unit...  I might have to upgrade to a full PC...........

Oops, I can't delete this topic, but I figured it out. I had the second client set with a static IP, but I dyslexia'd the IP, so it was not in the correct subnet. Delete this post if needed.

Are both sides PFsense?  Post your server1.conf and client1.conf. Nachtfalke already said it, but you're using a routed setup, you should be using TUN (not TAP). A couple things: 1.  Remove those client-specific override options, they are not needed.  (iroute is only used when the remote side is on a software client and that tunnel statement is redundant) 2.  Your advanced rules are redundant.  Those rules are already generated from the "IPv4 Remote Network/s" line. 3.  Remove the source restrictions from your firewall rules until you get it working…. i.e. on the OpenVPN tab, add an any/any rule to both sides (server and client)

[SOLVED] Fix will be available on 2.1.1

Hi All, I am now able to connect to the VPN, but the network through the VPN works for only 10 seconds, then I can see the gateway goes down, changing to red. Not sure what is happening here? Thanks, Dan

Missed a file in the last commit, it's 1.2.2 now, should be OK to try.

@kyreservoirdog: jg3, did you ever get this figured out? I did — apologies for not reporting back (bad form!).  I'm glad that you solved it but for the record: I have a 1:1 NAT for an host using an additional public IP (not the IP of the firewall).  There's a corner case or two where VPN'd clients would want to reach the internal host via the public IP.  So I had created another public-private 1:1 NAT rule and applied it to the OpenVPN interface.  This worked to solve the aforementioned problem, but caused the host the NAT applied to not to be able to connect to  VPN clients (other hosts on the internal nework could still connect to VPN clients). So, if you've come here looking for help … about all I can tell you is:  don't do that. --jg3

Found a fix at last, and would like to share it with you. it turns out that the ISP has changed some of their backbone routers. & I ended up doing this. 1. add mtu-test command in the advanced box of the Main OVPN Server. 2. check the logs of ovpn. 3. verify whats the local/remote mtu value 4. add the following to both local & remote (in advanced box) fragment 1400; mssfix;

Has anybody a similar configuration that works?

For anyone looking at this, i found the best guide to use here: http://hardforum.com/showthread.php?t=1663797

Yep that was my issue. Thanks!

Too easy  ;) Tested and fine. Could this be documented in the Wiki?

Op (I, that is) didn't take this OpenVPN FAQ seriously enough: One of the most common problems in setting up OpenVPN is that the two OpenVPN daemons on either side of the connection are unable to establish a TCP or UDP connection with each other. This is almost [always] a result of: … A software firewall running on the OpenVPN server machine itself is filtering incoming connections on port 1194 [here 5000-5007]. Be aware that many OSes will block incoming connections by default, unless configured otherwise. There's no problem with OpenVPN. I just neglected to create a firewall rule for WAN in the pfSense VM that's running the OpenVPN servers, to provide access for the hidden-service proxy in the Tor-gateway pfSense VM. How embarrassing. But this question should remain, I think, in case others make the same dumb mistake that I did.

Yes, in fact it just happened to me again with another VPN profile… Tunnelblick defaults to 2.2, so people that use Tunnelblick by default will have trouble with this until they change the OpenVPN version!  

as far as i know 1.1.4 and 1.1.5 have the verifiy-x509 removed for only the Yealink phones se this thread: http://forum.pfsense.org/index.php/topic,68398.15.html

Thanks for your reply.  I decided to abandon this configuration and instead not user OPTx interfaces for the OpenVPN tunnel interfaces.  Also I realized I don't need NAT between my internal VPNs and LANs.  So even that is simpler the new way. I do think that I misconfigured the outbound NATs and somehow that affected the original issue, but I can't say for sure. Thanks, Miki