Just set up different clients.  They will all get a /30 out of your tunnel network.

Sorry, but I am not going to rehash all the OpenVPN documentation again here.  doc.pfsense.org.

@eekay:

@viragomann:

I think your LAN hosts don't know the way to your VPN client and send their packets to the default gateway.
You should add a NAT rule to the VPN server, translating the source IP of packet from VPN clients to the servers LAN IP when they are going to LAN network.

Thanks for the reply. On the firewall/gateway, I currently have an additional gateway setup (vpn server) and also a static route that points all VPN network traffic to the VPN server. Is this not the correct way to do it? Should I remove these and use NAT instead? If so, what would the proper way to add an NAT rule to translate the source be?

No. You need a NAT rule on your VPN server for fixing that, not on pfSense. A VPN server is also a router on the other side and should be able to do NAT.
The NAT rule must translate the whole traffic coming from VPN clients to the servers LAN IP (172.28.35.22). This way response packets from other hosts are addressed to 172.28.35.22 and enter the VPN server where they are translated to client IPs.

opps thanks I have no clue why it was not showing the rules i rebooted and now it is.

Thank you :)

@viragomann:

Your LAN and WAN are in same subnet. Are they connected to the same virtual network?
If not maybe the traffic is miss-routed as a result.

thanks for replying see attached.

esxi.jpg
esxi.jpg_thumb

Worked Thanks!

And where are you checking th server?  Why do you have user root in there??

dev tun persist-tun persist-key cipher BF-CBC auth SHA1 tls-client client resolv-retry infinite remote snipped 443 tcp-client lport 0 verify-x509-name "pfsenseopenvpn" name pkcs12 pfSense-TCP-443-snipped.p12 tls-auth pfSense-TCP-443-snipped-tls.key 1 ns-cert-type server comp-lzo adaptive

server

dev ovpns1 verb 1 dev-type tun 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 tcp-server cipher BF-CBC auth SHA1 up /usr/local/sbin/ovpn-linkup down /usr/local/sbin/ovpn-linkdown local snipped tls-server server 10.0.8.0 255.255.255.0 client-config-dir /var/etc/openvpn-csc tls-verify "/usr/local/sbin/ovpn_auth_verify tls 'pfsenseopenvpn' 1" lport 443 management /var/etc/openvpn/server1.sock unix max-clients 2 push "route 192.168.1.0 255.255.255.0" push "route 192.168.2.0 255.255.255.0" push "route 192.168.3.0 255.255.255.0" push "dhcp-option DOMAIN local.lan" push "dhcp-option DNS 192.168.1.253" 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

servermode.png
servermode.png_thumb
clientcheckservercn.png
clientcheckservercn.png_thumb

Right I have found the issue. They are VMware installed and I didn't realise that promiscuous mode needed to be enable on the interface of the VMware side. You will also need forged transmits on.

No pushing of gateways is required, that gets handled automatically when the client connects to the OpenVPN server.

You can watch the process in action.
Go to the OpenVPN client icon, rgt-click->Edit Config then add the line "Verb 5" to the end of the config file and save it.
Reconnect the client to the OpenVPN server and "View Log" on the client after it connects.
You'll have a whole bunch of excess verbage, but near the end you'll see some lines like:

"C:\Windows\system32\route.exe ADD 192.168.x.x MASK 255.255.255.0 10.x.x.x"

These lines execute the Windows ROUTE command to tell your client how to send traffic to the OpenVPN server's network.

What subnets are you now using for:

pfSense LAN? OpenVPN tunnel? Remote PC's LAN?

These three items must all be unique networks as we said earlier.

@Derelict:

Your rule on OpenVPN was TCP only.  Ping is not TCP, it's ICMP.  Many protocols are not TCP.

Wow.  I must have looked at that rule and compared like 10 times and still missed that.  Yesterday was not my day.  I guess 12 hours of upgrading everything on my entire home network took a toll on me.

Thanks for that catch.

Thanks so much for the answer. Just what I needed!

This is my settings for «normal» openvpn client. LAN -> OpenVPN client -> OpenVPN gateway -> OpenVPN interface.

Make this a rule, but for OPT1. Maybe this will help you.

I made a virtual machine for the test (84,4 МБ).
Start VirtualBox. File -> Import -> pfSense.ova.
Start VM pfsense.
After start go to 192.168.1.10
Login admin
Pass pfsense
Menu VPN -> OpenVPN -> Client.
The settings in the screenshot.

An IPv4 protocol was selected, but the selected interface has no IPv4 address.

How fix this error?

disabling gateway monitoring fixed the problem. I guess cable is just variable and not clean.

Thank you dr41 and doktornotor forgot to do that. That at least resolves the error in the OpenVPN status window

However For some reason it still is an unidentified network with no internet or my "home" network access. I have a bridge in my pfsense config so I was wondering if the vpn server needs to be in the bridge as an enabled device.

No such thing there.

I have just used a road-warrior connection with SSL/TLS+User Auth to both a 2.1.5 and a 2.2.2 system. So it does work. I am using OpenVPN Manager on Windows 7 and config produced by the OpenVPN Client Export package. For me, it "just works".

TLS key negotiation failed to occur within 60 seconds (check your network connectivity)

That message usually means the client is simply not reaching the server - FQDN used by the client does not resolve to the proper server IP, server is not listening on the port…
Post your server settings, what client you are using, how you installed on the client.