@MartynK that's ok, it's a bit odd that a reboot was necessary. Maybe it was the MTU changes?

Finally!

The solution was creating a firewall rule that route the traffic of my Bridge interface through the gateway i have created for the wireguard client.

@mebert
Consider that you have to state the remote domain if you client uses another search domain, what I assume.

So if you want to request the remote host name is "host" and its domain is "local" you need to type "host.local" to access it.

@jarhead

I am configuring this device for deployment. Sorry I was not clear on that point. That is why the WAN is connected to my LAN. This device will be going over a thousand miles away and I need to set it up before it makes that journey. All of this headache just so I can remotely help (and make my life a little easier without needing to coordinate some kind of remote desktop/access). And this scenario requires the remote device to punch the hole through because their ISP uses private IPs, so the link will rely on the remote device establishing the link.

I have isolated it to the Firewall blocking the access. The default deny rule was stepping in to block it. The Firewall knows it is the S2S interface... and not the WAN. Private IP restrictions do not apply. The Default deny rule on both firewalls was blocking access. Oddly, the PC on the remote pfSense had no issues accessing my pfSense WebGUI but could not access my LAN devices... and I could not go the other direction to access the WebGUI of the remote device..

I need to review the syntax/scope on the Firewall rules again. By default, pfSense uses XXX net for Source. I had copied the allow rules to the S2S interface and updated to use S2S net. As Christian's video shows in the Firewall section, source is set to * (All). I have the tunnel working now. So sorry about wasting anyone's time.

P.S. Akismet is flagging my post as spam. Not sure why that is. Apparently it won't allow me to add images with the post.

@shahidge4
The tcpdump from WAN is pretty useless, since the connection is established already.

Your P2 has a single remote IP. So the VPN will only allow access to this one.
Do a packet capture on the IPSec interface.

Ensure that the remote host does not block access from the remote network.

So the P2 will effectively end up being (in my example) 10.200.10.0/24 to 10.100.10.0/24.
Each side 'hides' it;s local 10.10.10.0/24 subnet behind another, same sized, subnet. You could use any unused subnet for that I just chose 10.100.10.0 and 10.200.10.0.

So on each side that would be the Binat address.

https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/phase-2-nat.html

However if you do not need access between the two subnets dircetly but only from the pfSense_1 OpenVPN subnet this becomes easier. You only need to BiNAT on the pfSense_2 side like:

Screenshot from 2022-05-12 14-02-05.png

On the pfSense_1 side the P2 would be just be 172.10.10.0/24 to 10.100.10.0/24

To access the remote side VPN clients would need to use the equivalent NAT address.

Steve

@mpcjames glad I could help.

@viragomann Ok i got it working.
It took some cleaning up after previous attempts and I wouldn't make it work if it wasn't for you info.
Thanks

(L'adresse 20.0.0.1 n'est pas privée : ce n'est pas recommandé !)

Je ne comprends pas que vous ayez utilisé le MEME réseau pour le VPN site-à-site et le VPN roadwarrior ! Ce réglage ne peut que perturber le pfSense !

Il faut

configurer des réseaux différents pour le client OpenVPN et le serveur OpenVPN, en sus, pour les clients roadwarrior, il faudra ajouter une route (push route) pour qu'il atteigne le site Bureau.

Do you see it being routed in packet captures or the state table when you try to reach 1.1.1.1?

Where does it fail?

Thank you very much! Your solution fixed my problem! I missed to add the tunnel network to the remote networks on site B.

Ce n'est pas agréable de répondre et de se voir attribuer une attitude qui n'est pas la sienne ... C'est donc mieux.

Le VPN_ADMIN est le VPN roadwarrior (qui est très bien avec OpenVPN).
La config que vous indiquez me semble correcte cette fois ci.
Elle est logique puisque le Local est l'ensemble des réseaux de chaque site !
Usuellement, et la doc pfSense l'utilise, le Tunnel est 10.0.x.0/24 (ce qui permet à 63 clients de se connecter).
Si on a plusieurs sites, avec chacun un serveur OpenVPN, on fait varier le x : 8,9,10, ...

Le VPN_SITES devrait passer à IPsec et idéalement en maillé.
Donc chaque site doit avoir des définitions suivantes
pour le site 1 :
phase1 : vers site 2 / phase 2 : lan1 <-> lan2 / 2 rules ipsec : lan1 -> lan2 + lan2 -> lan1
idem pour site 3
idem pour site 4
et on recommence site par site

You could send some of that /27 across OpenVPN to the other site if the /27 is routed to you.

If the interface is a /27 that's going to be much more difficult.

In order for your roadwarrior clients to access resources @ site B, two things need to happen:

Site A's road warrior clients need to know that site B's LAN subnet should be routed down the tunnel Site B needs to know where to send the return traffic for site A's road warrior clients

Based on the above, the following adjustments should be made to the configs:

Site A:

Road Warrior config should have "192.168.20.0/24, 192.168.10.0/24" on the IPv4 Local network(s) line. (Remove 10.0.20.0/24).

Site B:

Re-verify the site-to-site config has "192.168.20.0/24, 10.0.20.0/24" on the IPv4 Remote network(s) line

Once the site-to-site tunnel is re-established and the clients re-connect, you should be good to go.

the routing table now is the same ?
maybe it was something else on the configuration