Okay!

Some more progress just after posting! Making the previous post made me find a misspelling of:
crt /var/etc/openvpn_client0.cert;

Which should have been

cert /var/etc/openvpn_client0.cert;

Now when I fixed that I get this error instead…

Apr 19 17:00:05 openvpn[9203]: Options error: Unrecognized option or missing parameter(s) in /var/etc/openvpn_client0.conf:33: script-security (2.0.6)
Apr 19 17:00:05 openvpn[9203]: Use –help for more information.

Set this option to push an IP to the client's interface. Expressed as a CIDR range (e.g. 10.5.0.0/16). The first IP in the range will be used as the remote IP of the interface, and the second IP will be used as the local IP of the interface.

In a PKI setup each client connects within its own /30 subnet.
The range you provide in the overall config defines how many such /30 subnets you can have.
ie: If you provide a /24 subnet for all clients there can actually 256/4 = 64 clients be connected at one time.

With the client specific config you can manually define which of these /30 subnet a client will use.

Doesn't matter, just got it working.  I tried using TCP port 80 and it worked (whereas TCP port 443 hasn't).  Funny old thing Open VPN but it does the job!

Wanted to close the loop on this one …
Did a fresh install on both ends and used my hand-coded confs (above) and it worked!

presumably there was something sticking around from the 1.2.x upgrade to 2.0 ...

These confs work but the ones produced from the GUI do not.

Updated - I had the syntax wrong, and didn't include my changes to vars.  This should be complete now.
–-----------------
I've got this working now, using a revoke-full script and some changes to the vars file.  Steps to revoke are:  run 'source ./vars' first, then ./revoke-full username, then post the new keys/crl.pem file to the configuration through the GUI.

Here is the script:

#!/bin/sh # revoke a certificate, regenerate CRL, # and verify revocation CRL="crl.pem" RT="revoke-test.pem" if [ $# -ne 1 ]; then     echo "usage: revoke-full <common-name>";     exit 1 fi if [ "$KEY_DIR" ]; then     cd "$KEY_DIR"     rm -f "$RT"     # set defaults     export KEY_CN=""     export KEY_OU=""     # revoke key and generate a new CRL     $OPENSSL ca -revoke "$1.crt" -config "$KEY_CONFIG"     # generate a new CRL -- try to be compatible with     # intermediate PKIs     $OPENSSL ca -gencrl -out "$CRL" -config "$KEY_CONFIG"     if [ -e export-ca.crt ]; then         cat export-ca.crt "$CRL" >"$RT"     else         cat ca.crt "$CRL" >"$RT"     fi fi</common-name>

And the changes to vars:

. . # Changes to allow for revoke-full option setenv KEY_OU "$KEY_ORG" setenv KEY_CN "my.servername.com"  #This should match the servername in your server cert setenv PKCS11_MODULE_PATH "$PKCS11TOOL" setenv PKCS11_PIN "dummy"

Hi Cry,

No it doesn't. The one I've blanked out is the ISP's gateway (which is on pfsense 2's WAN).

Still confused about how the other hosts connected to pfsense2 can reach the pfsense1 subnet

sigh

Got it sorted.

I was using policy based routing which screwed this up

Hello Micha,

Your issue seems very similar to mine.  See the thread below.

http://forum.pfsense.org/index.php/topic,15300.0.html

So far, I have not been able to resolve the issue.  However, I have made a similar discovery.  I had a terminal ping going in a session for 36 hours.  Once the tunnel is up it seems to be very stable.  I too have to attempt multiple times.  However, I did notice that while that one connection was active, I was much more likely to be able to establish a connection from another client on the first try.

I know that this information will not help you as such but it may be wise to watch each other's threads to see where things go.

I have actually decided to purchase a support contract and will be opening a case if I cannot figure this out.  At this point it seems unlikely that I will resolve myself.  I seem to have hit a brick wall due to my level of expertise it seems.

Good luck
Wayne

Try this method for making keys:
http://doc.pfsense.org/index.php/Easyrsa_for_pfSense

after speaking with some guys on irc, i did some tests and the tunnel it's active and the rutes are right, but i still can't access the lan behind the ovpn server :( any hints?

bravo83 may i ask which guide did you specifically follow to enable bridging on pfSense?
Thanks.

No problem.  Whenever you have time.  If you weren't a few thousand miles away I would offer my assistance. :)

thanks in any case i found the solution i make an alias where i put all subnets of vpn clients then i exclude this alias to use the load balancer and works both load balance and i can ping all vpn clients.

You missunderstand how the rules work.
http://forum.pfsense.org/index.php/topic,7001.0.html

Rules:
Rules are processed from top to down.
If a rule catches the rest of the rules is no longer considered.
Per default a "block all" rule is always in place (invisible below your own rules).

Traffic is filtered on the Interface on which traffic comes in.
So traffic comming in on the LAN-Interface will only be processed by the rules you define on the LAN tab.

A couple of reasons, my outside interface is using port 1194 the 12.166.84.3 ip is using 34246.

Each connection has a destination-port and a source-port.
Only the destination is 1194. The source can be something random between 1024+ ~ 65535.

Please give a little more information on your configuration.  Is this firewall to firewall, or a host to your firewall?  Is this PKI or shared key?  What are the networks involved?  How is OpenVPN configured?  It sounds like you're not trying to do anything fancy, so if you can give more details, I might be able to help.

Huh… No one is willing/able to verify?  I'd hate to raise a bug just to find out that it's an existing bug or only in my config.

We can close this issue.

Jimp you are right. The problem why the IP-Address 192.168.11.2 doesn't response my requests was the gateway.
I tried antother IP and I could see all things are working.

The Push command brings up the solution - THANKS !!!

so…yesterday i uppgraded my firewall to 1.2.3 and now the tun interfaces (OpenVPN interfaces) show up in the GUI. I've adde them as optional interfaces. The thing is when i create rules for these interfaces nothing happens so i guess this is not supported? But...when i look in the firewal logs, i can se the occational packet beeing blocked on the tun0 or tun1 interface?

Is there anyone who can bring some light as to why the tun interfaces show up in 1.2.3 and if they can be filtered?

I just ran the command "pfctl -sr" on my pfsense box and it seems that the rules i've created for the tun interfaces are there. I'm no master of pf so i will have to spend some time decoding this printout.