(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

Why do you use a /24 net for a site-2-site. A /30 will be the better choice here.

@Cricco95 said in OpenVPN site2site not working:

Trying to ping VPN server interface on 10.8.0.1:

You did the ping from WAN IP. Don't know what your WAN is, but you may miss the route.

What it you do a ping from LAN?
If it works, try a ping from LAN to the remote LAN IP of the server.

For anyone who is interested (n00b here), i got it to work (branch to pfsense only):

Phase 1 remote subnet on pfsense has to be 0.0.0.0 with responder only option checked.

on Huawei Side, the following command had to be configured:

ipsec authentication sha2 compatible enable

the result is:

22accdc1-de10-456f-beb1-06c813df2382-image.png

The problem now is that pfsense does not direct traffic with destination to remote subnet (i.e. 10.2.20.0) through IPSec, it uses WAN0 for that. any ideas?

[update] working now, was pinging from the wrong device.

you can have multiple tunnel configured, i don't see why not

@EFP-TechTeam said in pfSense OpenVPN site-to-site client dies every day or two.:

The logs don't give a lot of clues.

What do they say?

Well, I have just got it working. The solution may be very specific to my scenario.

First, I need to go through and test all the individual changes I made to ensure each one was needed, remove the cruft that was not needed and I will post the final solution here there after.

What I had to do in this scenario was go Pfsense A, go to advance settings of IPsec, From there:

Auto-exclude LAN address Enable bypass for LAN interface IP Exclude traffic from LAN subnet to LAN IP address from IPsec.

This box was checked by default.

I cleared it and traffic is now working both ways.

I suspect what mattered here was the fact that Pfsense A didn't have a LAN subnet, and OpenVPN client subnet may have been seen as a LAN by this rule. I am sure one of the Pfsense developers could provide an explanation.

Now I just need to check all the routes, rules, Phase 2 parts to ensure they are needed.

32ms across IPsec?

If so it sounds like you're getting right about what you should for a single-stream TCP session with 32ms latency and a 128KB buffer.

That is probably a little high since you have the 30Mbit upstream at one end and certainly not a 1460 MSS across IPsec.

Bandwidth-delay Product and buffer size BDP (1000 Mbit/sec, 32.0 ms) = 4.00 MByte required tcp buffer to reach 1000 Mbps with RTT of 32.0 ms >= 3906.2 KByte maximum throughput with a TCP window of 128 KByte and RTT of 32.0 ms <= **32.77 Mbit/sec.**

You could try giving a -P4 or -P8 to the iperf client to see if running multiple streams helps.

Or switch to UDP and see how high you can take the -b parameter before you start experiencing loss.