Post a network map.  Post the openvpn config (server1.conf, client1.conf) from both sides.

That's what I figured, but couldn't post 'til now.  Since 2.x, you can enter multiple subnets into the GUI and the routing directives will be generated automatically.

@Derelict:

There is really no reason to use different IP addresses for that.  One IP address can have multiple outbound OpenVPN client connections.  You would then use policy routing to send traffic from, say, 192.168.1.2 out the correct OpenVPN client connection.

But if you really want to, I believe you would create VIPs on WAN for the IP addresses then select that VIP as the Interface in your OpenVPN client config.

Thanks for the prompt response. I have tried that initially, but every time I have an OpenVPN client established, I loose WAN traffic even at the default gateway (non-openvpn directed) level. I saw a guide for Private Internet Access, where they used one of the available interfaces to dedicate OpenVPN traffic. I gathered the point of doing so was to reinforce the requirement to use the OpenVPN and maybe not to have an imperfect messy NAT chain of rules.

I have tried both ways.

I don't mind utilizing OpenVPN client connections on the same IP, however right now I haven't filled all thats paid for, so I thought to dedicate two IPs for use of pftop viewing at a glance and maybe some analyzing down the road.

Don't know, dude.  It works every time I do it.

yes thats the "unless you are satisfied with static/fixed ip's " approach

Are all the other steps required to set up a VPN the same?

Yes, the OpenVPN server running on pfSense only needs to know that it should be "listening" for connections on the WAN NIC (or whichever one you choose).
It doesn't care how someone outside your network finds the address of the WAN NIC, that's their problem.
DDNS solves that problem by giving you an easy to remember domain name that is translated behind the scenes into the external IP address of the WAN NIC.

The great "Client Export" package makes it easy to install the correct client with all the settings for DDNS, certificates, etc. preset for you.

I just had this discussion with someone else recently and it takes far more time to describe the process of making this all work than to actually do it.
It really is fairly simple once you see it in action, try it out and we'll help as necessary.

Thanks for your answer and your link to the docs. I generated my own already a month ago which I feel is more safe then using the default :).

I had this same problem but for different reasons.

I created the user first, and didn't check the box to create a user certificate.  The user certificate is optional when defining users, but is a requirement for the user to be listed under openvpn client export.

Perhaps a note in the openvpn page under the Authentication heading could include that it's not enough only to define users under System > User Manager but they must be defined with a user certificate.

Even better, I should get off the 192.168.1.0/24 space and both my issues are gone.

ok
maybe

Thank you very much anyway

First, make sure that your radius server is receiving Acces Requests from your VPN server and that it is sending replies.
you can filter packets using tcpdump tcpdump -X -i vmx0 -s0 port 1812 for example.

For OpenVPN logs under pfsense go to "Services->System logs-> OpenVPN"

@marvosa:

Post the IP range for each segment as well as your OpenVPN config (server1.conf).

First of all, thank you for the reply marvosa, appreciate the help, here's the IP ranges for each interface:

APPSERVER- 192.168.97.1/24 (Static IPv4 and DHCP enabled).
MGT - 10.0.0.90/24 (Static IPv4, this connection is setup as LAN, meaning this is the IP address I use to connect to my pfSense machine).
And the other two (NETGEAR and DLINK) are setup as PPPoE WAN connections, meaning they're getting their IP address from my ISP.

Also, here's the OpenVPN server1.conf file:

dev ovpns1 verb 1 dev-type tun tun-ipv6 dev-node /dev/tun1 writepid /var/run/openvpn_server1.pid #user nobody #group nobody script-security 3 daemon keepalive 10 60 ping-timer-rem persist-tun persist-key proto udp cipher AES-256-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown client-connect /usr/local/sbin/openvpn.attributes.sh client-disconnect /usr/local/sbin/openvpn.attributes.sh local 93.173.17.8 tls-server server 10.0.1.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc username-as-common-name auth-user-pass-verify "/usr/local/sbin/ovpn_auth_verify user 'Local Database' false server1" via-env tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'opvtest+UCA' 1" lport 1194 management /var/etc/openvpn/server1.sock unix max-clients 10 push "route 10.0.0.0 255.255.255.0" ca /var/etc/openvpn/server1.ca cert /var/etc/openvpn/server1.cert key /var/etc/openvpn/server1.key dh /etc/dh-parameters.2048 tls-auth /var/etc/openvpn/server1.tls-auth 0 comp-lzo adaptive persist-remote-ip float topology subnet

Currently there is no way to accomplish that.

But the good news is that if you are saving the auth locally, just get rid of the auth, it does you no good. TLS Key + Certs alone is fine if you are making the auth a non-factor by saving it anyhow.

Thank you doktornotor!

I'll check this out!

I managed to find out the problem:

In the configuration file of the OpenVPN server located in /var/etc/openvpn/server1.conf:

client-connect /usr/local/sbin/openvpn.attributes.sh
client-disconnect /usr/local/sbin/openvpn.attributes.sh

The first line is responsible of adding attributes to the connecting clients, one of these attributes is the Radius attribute "Frame-IP-Address".

These scripts get overridden if the client-connect and client-disconnect were added to the advanced configuration of OpenVPN.

So to solve the problem, I deleted the "connect-client" entry from the advanced configuration and modified /usr/local/sbin/openvpn.attributes.sh with the necessary lines to execute (the lines I had in my old client-connect script).

@2chemlud:

I don't even get what is not working in your setup…

No wonder, with terminology like "see internet traffic on client". Why should some OpenVPN client "see internet traffic"?

Same Problem here

OpenVPN Server log:
openvpn[]: 91.xx.xx.xx:1194 TLS: Initial packet from [AF_INET]91.xx.xx.xx:1194, sid=81e8d10a
openvpn[]: 91.xx.xx.xx:1194 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
openvpn[]: 91.xx.xx.xx:1194 TLS Error: TLS handshake failed
openvpn[]: 91.xx.xx.xx:1194 SIGUSR1[soft,tls-error] received, client-instance restarting