I found it! For some reason, I had a 1:1 NAT entry pointing the 1st IP of my external address block to the internal IP address of the pfsense box. This kills it of course.

Glad to help you! I don't think you need to change anything.

These are P2P connections and I have the network specified in the remote networks of the main firewall. Also the route appears in both the main firewall and my remote client firewall. I can also try adding push route to the advanced options and will get the same result.

Tried a reboot, but no change… From the pfsense: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ovpns5, link-type NULL (BSD loopback), capture size 65535 bytes 22:06:25.727660 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 7, length 64 22:06:26.727671 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 8, length 64 22:06:27.727676 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 9, length 64 22:06:28.727686 IP 172.16.254.21 > 172.16.101.16: ICMP echo request, id 25565, seq 10, length 64 22:06:32.620809 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64 22:06:32.920929 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64 22:06:33.621049 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64 22:06:33.921304 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64 And from the remote end Linux host: tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes 17:36:32.798639 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 1, length 64 17:36:32.798655 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 1, length 64 17:36:33.799001 IP 172.16.254.21 > 192.168.73.2: ICMP echo request, id 25566, seq 2, length 64 17:36:33.799024 IP 192.168.73.2 > 172.16.254.21: ICMP echo reply, id 25566, seq 2, length 64 It only sees the traffic to the tunnel ip, not any of the traffic destined for hosts beyond

Well I have a more fundamental issue.. my provider has different TLS keys for every server and so I'm trying to figure out how to have multiple remote statements with different TLS keys. I found that as of a recent OpenVPN version, there's a notion of connection profiles, specified using <connection>tags in which you can have targeted parameters, but unfortunately they are specific ones, so I've opened a feature request with OpenVPN to allow the tls-auth and ideally cert directives to be included so you can have per-server settings. I need this to be able to have my client try different servers within the same country when one goes down. For my direct question, I've found a workaround where I can just specify an external openvpn config file with the inline configuration and it works.</connection>

@dbennett: I want only specific IP's listed in an alias to go through the tunnel.  If place a value in the 'Remote networks' box will that cause any issues with traffic leaving the 'Server' site to the WAN? That just sets the route to the networks behind the client to the clients IP if the connection is up. It will have an private IP range. Your server cannot reach this network over WAN. You can also enter single hosts in this fields. @dbennett: I created an interface / Gateway for the site to site (S2S) along with an Outbound NAT rule for the Client connection to route through that interface and gateway.  I did the same thing for the S2S Server.  So I should have two OpenVPN interfaces / gateways on the client side; one for that site's server (1194) and for the S2S Client traffic (1195)? That's alright. However, bear in mind that you have to define your VPN firewall rules on this new interfaces now.

I think here you will find some useful information https://forum.pfsense.org/index.php?topic=116626.0

Well if your wan IP is rfc1918, then pick other and put in your actual PUBLIC IP..  Do you know what that is? Is that really confusing for you??  Not sure how this has anything to do with pfsense.. Do you not understand what a rfc1918 address is or that 192.168.x.x is not viable address on the public internet?  Your the admin?? No offense just confused how this is confusing?

Why don't you just ask him? It is not unreasonable in my opinion as scope tends to creep to LAN-side things eventually. Regarding logging you could turn on logging on the VPN rules. That will log every connection over the VPN. It might be pretty voluminous. Make him call to get access and enable/disable the account accordingly if that helps you feel better. With just HTTPS access he can make a VPN/ssh tunnel, etc any time he feels like it anyway. If you don't trust him you're probably using the wrong guy in the first place.

no your openvpn being udp is just the tunnel, what your seeing is blocks inside the tunnel.

Hi Jimp, I very appreciate your perfect answer, i followed your tipps and now everything is working like a charm, this make my life a lot easyer ;) Best REgards Marco

Usually just a setting in openvpn's server config.  I stopped using it for another reason (reload then it wouldn't work again lol).

Dear sir can you explain how did you do it ? please many thanks

Ok, this: if ( ! openssl_pkcs12_export_to_file( $req_cert, "user.p12", $req_key, "" ) ) is the problem. The .p12 produced only contains the user cert - I need to add the CA cert as well. However, it doesn't look like there's a php openssl_ function to do this - which is probably why the openVPN Client Export Plugin uses: exec("/usr/bin/openssl pkcs12 -export -in {$ecrtpath} -inkey {$ekeypath} -certfile {$ecapath} -out {$eoutpath} -passout pass:{$eoutpass}");

Yeah how else would you skin that cat? ;)  If you want user X to be allowed access to device at 1.2.3.4, then yeah you need to make sure user X always has IP address 2.3.4.5 so you can allow that via firewall rule.. User Y that gets something other than 2.3.4.5 would not have access.. If you have groups of users that all need same access you could just create different vpn connections so that users A,B and C would always get ips in network 1.2.3.0/24 and you could then create the firewall rules on that network vs specific IP and if you have other group of users that need different access then AB and C then they could be on entwork 1.2.4/24 etc..