Hmm, even with rules that allow everything, still no success..

You referred to an article that referenced setting separate, static addresses. That's what was provided. I do not think there is another way to set another pool in a CSO. I could be wrong. I would just run another server for that.

Hi, Thanks for the reply. You are correct: it does work out of the box. T he probleem seems to be just ONE system (and that happened to be the one I was using as a reference to check if it works) that cannot be reached. I will further investigate the problem with this one system but it is probably not of interest to the community what the problem is so we can close this thread. regards.

I found a solution. Set the IP of your LAN interface to none and set the firewalls IP on the BRIDGE interface itself. I did this by downloading the config, editing the XML and uploading the config again. I tried doing it from the WebUI but accidently broke my network because I couldn't remove and add the IP to to the other interface at the same time. Hope this helps.

Is there any way we can get manual updates to vulnerable packages or are we just expected to wait for the next major/minor release? For a system that sits on the front lines of a LAN, I really would prefer that it's as secure as possible. According to 'pkg audit', I have 4 packages that need patched in pfsense v2.3.4.

Connect the vlan 3 to the vpn connection.

It may have the same cause as the problem at https://forum.pfsense.org/index.php?topic=127274 "Short hostnames not working on 2.3.3" There you have to make a change in the dns forwarder settings to get it working properly after a reboot. It does not matter what you change. It looks like some post-boot trigger is missing somewhere.

Pretty sure when you buy hardware you get 2 free support calls included in the price.  I did when bought the sg-2440.  Haven't used yet, prob never need them - but nice to know they are there if needed.. For setting up road warrior - you click through the wizard, then go to the export package and download you config.  Done! Now what I did run into recently, is that the ios app does not support the newer tls-crypt feature of 2.4 openvpn.. So you have to make sure your just using tls auth and not crypt.. I would suggest you post up your config, post up your logs from client and server and we can figure out what you are doing wrong.

@tgilcas: Thanks a lot for your help, i added pfsense as gatway on vm windows server. but did not helped. so what i did was in pfsense in dchp was adding static ip to the windows server and then i changed windows server ipv4 to get automatic ip, now i can make ping from vpn, i cant do the same to exsi host server. so, why is this? why if i put statics ip on the windows it does not work? any suggestions? You need to rephrase this.  It's unclear what was done to what…  and what is working and what is not. Also, to go much further, you'll need to provide more specifics about your topology.  Without specifics, your issue could be related to a dozen different things and we'd just be taking shots in the dark which is inefficient at best. Post a network map showing your topology and subnets in use Where are you testing from? Post your server1.conf The fact that PFsense is virtualized also adds another layer of complexity.  We'll need details on your ESXi setup.

@Finger79: Honestly, it'd be nice for more granular control of the .ovpn config file via the GUI (i.e., the entire config).  For example, persist-key and persist-tun and resolv-retry-infinite are simply hard-coded now, and if we manually edit the text file, it gets overwritten whenever the Service restarts. My pipe dream would be a GUI that dynamically builds the config file, but there's a drop-down element for "every" possible directive.  This would take a lot of coding probably. Or an easier option:  Simply create an "Advanced Mode" in the GUI that lets us have 100% control over the config file without inserting anything. My sentiments exactly. One of my pet peeves is partially implemented features/capabilities etc.  That's why I did the advanced option for DHCP client a few years ago.  Nearly everything is settable via the GUI advanced options.  But for the rare cases of something not being there or a bug, etc.  A config file override option is available to put a DHCP client config file anywhere you please and point the GUI config at it.

There's a lot of commercial VPN users in this forum.  Surely not everyone is hard-coding an IP address.  What is everyone here doing to get around this issue? I spent a ton of hours experimenting today.  I migrated from dnsmasq to unbound, but same results.  I disabled the first NAT rule "localhost to PIA" but same results. The next thing I'd like to try is to remove the persist-tun directive, but it's hard-coded.  No matter what I do, it's there. From the manual: @OpenVPN: –persist-tun     Don't close and reopen TUN/TAP device or run up/down scripts across SIGUSR1 or --ping-restart restarts. SIGUSR1 is a restart signal similar to SIGHUP, but which offers finer-grained control over reset options. I'm thinking whenever I get a SIGUSR1 reset, I do want to close and reopen the TUN device, which would trigger a new name resolution query.

In a routed tunnel, all subnets on both sides need to be unique and it looks like there may be either some overlap, a typo or possibly a misunderstanding.  In your OP, you stated the client's LAN was 10.2.0.0/24, but per the client's config, the client's WAN has an address of 10.2.0.1, which tells me the client's PFsense box is double NAT'd behind another edge device (not recommended), which may need to be addressed first depending on what's "not working". Just fixed that, accidentally selected the LAN interface for it instead of WAN. On the server side, the server is routing 10.2.0.0/24 down the tunnel, but that is the LAN behind the client's current edge device… that's not the LAN behind PFsense.  You will need to acquire the LAN subnet behind PFsense and adjust the "IPv4 Remote network(s)" line accordingly. Guessing that was fixed by fixing the interface issue? The two sites have mismatched device modes.  The client is using device mode "TAP" while the server is using device mode "TUN".  In a routed solution, the device mode needs to be "TUN". Just fixed that on the client, didn't fix anything Here's my routes without the VPN connected: Destination Gateway Flags Use Mtu Netif Expire default 66.229.104.1 UGS 913103 1500 bge0 10.2.0.0/24 link#2 U 2468145 1500 bge1 10.2.0.1 link#2 UHS 0 16384 lo0 66.229.104.0/21 link#1 U 5409 1500 bge0 66.229.107.166 link#1 UHS 0 16384 lo0 127.0.0.1 link#6 UH 0 16384 lo0

Fixed problem with access. Many thanks to all responded! The solution is to enable forged transmits on a distribution switch (LAN interface). In pfsense is also not a problem. Bug proved in the settings of the switches. [image: scr0.JPG] [image: scr0.JPG_thumb]