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: [image: 1565666662782-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.