@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]

Pass rule on the OpenVPN tab for his source address port any server's dest address port 443 Reject rule for his source address dest any You will also need to pass DNS, etc if that needs to work over the tunnel.

Ok yeah worked perfect this time. i think the open vpn client was recently updated or something because it did not work the last time i tried that plugin. The all in one config and program installer was the step i was missing. Works now! thanks very much.

Thank you for your help Derelict. I have now disabled the DHCP on the VPN. I also didn't know that there was a way to change the monitoring ip address. I have now done this too. I also needed to add "comp-lzo" like sneakking suggests in the previous post. (https://forum.pfsense.org/index.php?topic=129576.msg718034#msg718034) Now everything is working.

You need to do two things in order to access the network(s) behind your clients: You have to add an iroute statement for each network you want to access in the client specific overrides section for that particular client You have to enable IP routing on the client PC -> https://gist.github.com/mouseroot/5489960

@marvosa: After adding the NAT outbound rule in the firewall all is fine. I can access all machines on 10.32.0.0/16 without issues. Just SIP RTP to my PBX is not working, but I think that's more on the PBX side as I think it'll pass the outside IP in the SIP headers because it thinks 10.250.250.0/24 is an outside IP. I'm negotiating this with the PBX mfr. @dhoffman98: I know these problems g … especially when traveling and the hotel WiFi is in the same 10.x IP range I use and I can't access my network from my notebook. Since a few months I've always got my GL-AR300M with me which decouples the IP range for my devices from that ;-) Also a reason to choose 10.250.250.x as VPN IP range ... that does normally not collide with anything.

@Derelict: Your multi-wan rules are policy routing the traffic you want to go to the OpenVPN tunnel subnet out the WAN interface instead. Bypass policy routing for the OpenVPN tunnel subnet on your LAN rules. https://doc.pfsense.org/index.php/Bypassing_Policy_Routing Derelict, Thank so much! That page described my situation exactly, and such an easy fix. My application is working great now. I can't thank you enough. I'm still a little puzzled by why the ICMP and TCP traffic seemingly were treated differently, but I never argue with success.

The DNS servers given out to the clients VIA DHCP are all pointing to the firewall (192.168.1.1).

It looks like I've solved it, and, as Derelict said, it was a policy routing issue.  My firewall rule for allowing traffic from that interface out to the WAN was missing a Gateway.  It was: Pass IPv4 *  GUEST_LAN net  *  *  *  *  none      GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled) and I changed it to: Pass IPv4 *  GUEST_LAN net  *  *  *  WAN_DHCP  none      GUEST_LAN: Pass WAN (Pass Any, But Local Already Handled) I assume the issue was that I hadn't specified how the traffic was supposed to leave, so it defaulted to whatever the system was set up to use.  Before the "redirect-gateway," that was the the WAN.  Afterward, it was the VPN.  Once I added the gateway, that got specific enough to override the use of the VPN and actually use the WAN.

Thanks for your reply, Yes I set up site to site connection and connection state is also up. when I'm exporting the same configuration and using in a windows PC everything works in expected way, and in client pfsense router also in states looks everything fine and even receives the intended IP address from site one DHCP, my question is now my router has three ports: one is connected WAN one is connected LAN and one is free, when I connect my pc to LAN port it received IP from my current network (network of site2) not receiving IP from site1 DHCP, I really have no Idea I tried to bridge between LAN and openvpn port and other tricks but nothing worked and hope someone help me what to do that every pc in sited 2 connected to pfsense client router receive ip from site 2 DHCP.