Hi Derelict, I should have checked the bugtracker:-) But thanks for your response.

I would just spring the $9 on Viscosity and call it a day. Create the OpenVPN server and use the client export package to generate your configuration. Import it into Viscosity and you are done.

sorted !!! what i did was create a "client specific override" common name rob and ip 10.100.3.10/24 and this is my rule https://s31.postimg.org/pxsqg9env/openvpn_rules.png now i can only talk to 10.100.1.253 which is my switch, if i try 10.100.1.254 which is my router i cannot get access to it thanks rob

@Derelict: You need to set the search domain properly on the client if you expect it to append the domain name in a lookup. Try resolving the FQDN. If that works it's a search domain problem. Precisely correct.  I thought I had tried that but I went back through and looked at my previous pings and found I had misspelled it.  This is primarily for VPN protected RDP access so I can just use the FQDN of the server and it pops them in just fine.  Thanks again for your help!  You learn something new every day!

@Derelict: I did that manually and it worked fine. Could you please compare my configuration with yours? Here a the relevant part of the server config and override file: --- /var/etc/openvpn/server4.conf --- server 10.9.0.0 255.255.255.128 ifconfig 10.9.0.1 10.9.0.2 route 192.168.1.0 255.255.255.0 topology subnet route 10.9.0.128 255.255.255.128 --- /var/etc/openvpn-csc/server4/username --- push "route 10.0.1.0 255.255.255.0" iroute 192.168.1.0 255.255.255.0 ifconfig-push 10.9.0.134 255.255.255.128 With this configuration - client IP is not on "server" subnet- I get the error message I mentioned earlier. As I'm reading OpenVPN documentation I realize that server configuration page needs some modification in order to support pool configuration with topology subnet.

Any updates please

Guys problem solved, For some reason unknown to me yet, PFBlockeNg was blocking access to pinging and HTTPS sites of the remote network. Http sites worked normally. Once I disabled PFBlockerNG, everything works as expected. Now I have to find the setting in PFBlockerNG to allow simultaneous operation of Site 2 Site VPN and PFBlockerNG . Any recommendation is welcome.

Nothing special to it. Make sure your destination IP address has a route sending it through your other VPN and it will do the rest on its own. You'll be slowed down by having to encrypt/decrypt everything twice, and you'll lose even more bytes per packet to overhead, but otherwise it should work.

It's entirely possible that AD does the right thing and OpenLDAP-based systems fail that test. Strengthens the case that it's not a pfSense issue, but a problem on the authentication server.

It's also been fixed in the repository for a while now: https://redmine.pfsense.org/issues/8391

Try this guide https://nguvu.org/pfsense/pfsense-inbound_vpn/ It has some useful tips.

https://www.speedguide.net/analyzer.php Here's where I get the values: 1397 MTU(now after testing tun-mtu values) 1357 MSS I currently have these advanced options set: fixmss; tun-mtu:1400 I was able to confirm these are functional after setting the MTU to 1300 and getting that result on the test above. but with 1400, it seems 1397 is the best I can do, which makes sense if the MSS of non-tunneled packets is 1460 (40bytes of headers) - another 40 bytes for encapsulated packets = 1420, so it seems there's about 23 bytes of OpenVPN headers for TLS/SSL authentication. I was just hoping to get as close to the 1420 I've seen in IPsec as possible. I'm not using IPSec because of the routing functionality. I set the tun-mtu to 1402 and the tested result still returns the above results with MTU 1397

Oh, thx for that plausible example. That makes sense ;)

https://doc.pfsense.org/index.php/How_can_I_forward_ports_with_pfSense https://doc.pfsense.org/index.php/Port_Forward_Troubleshooting You will want to put the port forward on the OpenVPN assigned interface. You will want to be sure the rules on the OpenVPN interface group tab DO NOT match the port forwarded traffic. In fact, if this is your only OpvnVPN client, just delete/disable all rules on the OpenVPN tab.

It is just the way OpenVPN works. That route gets traffic for the /24 into OpenVPN. From there OpenVPN does the right thing.

@ashima: Hi, That is possible if you are having site-2-site openvpn connection. Then all the systems from Client A side can access 192.168.20.x series and vice versa. As far as I can understand from your post  is that you are running windows based openvpn client software  on individual systems on Client A. If that is the case then I guess you will  not able to access systems on Client A side from 192.168.20.x. I suggest to put up a device (may be another pfsense device) at Client A and then the two devices can make a openvpn connection. Then all the devices from either side should be able to talk to each other. regards, Ashima Thanks to all, following the Ashima suggestion I solved the problem, I just bought a simple router board  Mikrotik RB260GS and make the connection  site to site open VPN, So now is solved. Thanks to all for your cooperation, all the best. Gully

I have worked around this situation by just using the VPN server's IP address instead of its hostname in the VPN client config.

Apologies for the delayed response. I have to walk away as this was doing my head in. It can't be this hard… I have a VPN tunnel established between server and client1 (10.0.8.1 & 10.0.8.2) Both server & client1 have openVPN fw rules allowing full access. Server LAN can ping 10.0.8.1 & 10.0.8.2 Server pfSense can ping 10.0.8.1 & 10.0.8.2 Client1 LAN can only ping 10.0.8.2 Client1 pfSense can ping 10.0.8.1 & 10.0.8.2 Does this sound correct or does this indicate a problem?