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.
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.
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
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.
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.