It is working! if somebody has this problem just add the google DNS or your internet provider DNS and its working!Thanks for the help ! ;D

What was set as the tunnel network in the OpenVPN server and the clients?  This stuff kinda just works. Are you sure you need mesh?  Hub-spoke is a lot easier to maintain.

normally you should be able to use the export utility every time, and it should add a seperate "menu' for each openvpn connection (when you rightclick the icon in the tray). the only reason i know that this fails is: –> your pfsense systems all have the same hostname+domain. (system->general setup) so if thats the case, make them different/unique from eachother and reboot the boxes. then try the client export utility again.

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. [image: esxi.jpg] [image: 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 [image: servermode.png] [image: servermode.png_thumb] [image: clientcheckservercn.png] [image: 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. [image: thumb.png] 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. [image: thumb.png] 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.