@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

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.