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.