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.

I've been running a Syslog server so I can record the activity logs for my pfSense box, but there are aren't any notable errors or warnings. I used to only capture OpenVPN logs, but changed it to all when I wasn't getting any useful data. I was getting a lot of Authenticate/Decrypt packet error: bad packet ID errors so I changed my OpenVPN client from UDP to TCP. 2017-05-21 14:14:23 Daemon.Error 192.168.1.1 May 21 14:14:22 openvpn[43547]: Authenticate/Decrypt packet error: bad packet ID (may be a replay): [ #2241995 ] -- see the man page entry for --no-replay and --replay-window for more info or silence this warning with --mute-replay-warnings The network still loses connectivity on TCP, and the only other unusual thing that the log shows is that the unbound service has a tendency to restart a lot. 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: Restart of unbound 1.6.1. 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: init module 0: iterator 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: start of service (unbound 1.6.1). 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: service stopped (unbound 1.6.1). 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 0: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 0: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 1: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 1: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 2: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 2: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 3: 0 queries, 0 answers from cache, 0 recursions, 0 prefetch, 0 rejected by ip ratelimiting 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: server stats for thread 3: requestlist max 0 avg 0 exceeded 0 jostled 0 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: Restart of unbound 1.6.1. 2017-05-21 16:41:09 Daemon.Notice 192.168.1.1 May 21 16:41:07 unbound: [35012:0] notice: init module 0: iterator 2017-05-21 16:41:09 Daemon.Info 192.168.1.1 May 21 16:41:07 unbound: [35012:0] info: start of service (unbound 1.6.1). Other than that the only thing the logs show are numerous filterlog entries.

Just thought I'd chime in and say I resolved a similar issue by disabling 1:2200073  SURICATA IPv4 invalid checksum It was blocking PIA.

What do your IP addresses look like?  Do you have firewall rules to allow the traffic coming from your VPN clients' interface access to your local devices?

I found a way to test udp using Packet Sender (https://packetsender.com/) on the local computer and a remote computer (outside my network). One computer sends a udp packet and the other receives it and reply. I found 2 things: Remote computer -> pfSense -> Local computer (192.168.20.125): It works ! The port forwarding actually works ! I even get a reply (no clue how that's possible) since… Local computer (192.168.20.125) -> pfSense -> Remote computer: Fails, pfSense never seeds the packet to the VPN. So, it's not a port forwarding issue. I'm guessing it's a NAT issue or a routing issue (is there a difference ?). Not quite sure what to do about that... Not even sure this is related to OpenVPN... Should I start an other threat ?

Unfortunately it's not client firewalls either, I checked that. I can only think it's broken for me (or me that's broken!). I'm going to see if IPSEC works any better, or helps me diagnose the problem, but that's not looking good at the moment either. That's saying auth failed, when the pre-shared secret is definitely identical. I'm missing something obvious and daft clearly! Trawl the internet and docs read and re-read I guess. No Idea what is going on with openvpn and site-to-site, but I got IPSec working fairly quickly. So I'm happier with IPSec for site-to-site anyway - I can only think there is something broken with openvpn site to site with my setup somehow.

It is in the client exporter. Use the dynamic DNS name which should be available under Host Name Resolution if you are using pfSense to maintain the DynDNS record. If you are maintaining it some other way, use Other and enter the dyndns name there. You will probably also need to create a new OpenVPN server certificate with a CN AND a SAN of the dynamic DNS name, not an IP address.

Solved my DNS query refused by adding the correct ACL to the DNS Resolver for OpenVPN.  Funny how the UDP VPN connection worked without any ACL.