@kamil-0 opcjach serwera OpenVPN odchacz opcję "Inter-client communication". Komunikacja między klientami nie powinna działać. Ale jak wrócę do domu to sprawdzę.

I still haven't figured out why this is happening. The only update I have is that I've also tested this on macOS using the official openVPN client and I had the same results: perfect upload speeds (to the server) and terrible download speeds (from the server).

I don't know what else to try at this point.

@viragomann Thanks for the reply! I have checked this box, however when I do reload the tunnel (momentarily dropping it) traffic does route to the other network card, so it must not be blocking it

OK, so deep diving, this does not function as expected in pfSense if you try and chain CA certificates. It just doesn't and hard-fails.

The only way to do this is to use a single-tier OpenVPN Certificate Authority and then things just work. Unfortunate, but this is a solution we can work with (everything's stored in a X.509 cert management utility so nothing is lost and everything is equally secure).

Just annoying I can't use the intermediate chains...

@johnsheridan Thanks for the info and testing. That makes sense. I’ll have a look at those files and patch.

This will be probably fixed in one of the next releases then.

So your on-prem Webserver is also running as OpenVPN client which is connected to your gcloud pfSense? You are only running this one pfSense? What is your OpenVPN mode?

-Rico

Hallo Zusammen,

vielen Dank für die vielen Antworten.
Ich werde das ganze am Wochenende mal trennen.
Das macht Sinn ja. :)
Aktuell komme ich nur nicht dazu, weshalb das ganze hier etwas eingeschlafen ist.
Bei einem anderen Peer klappts scheinbar.
Sehe merkwürdig.
Aber ja, trennen macht sinn.

Danke erstmal.

Hi,
Because of the differences, is it still a question for me which pfSense version is this?
(for example, it's a difference...)

a5e04914-dd2a-4541-837e-1c1e7326f70d-image.png

The second important thing is server mode (you use TLS), but that's all I see:

a4666822-e747-4e05-9657-82e796510e7c-image.png

instead of:

0b4e10a0-be71-4b2c-ad2c-d118a3478c69-image.png

I don't see your own cert for the connection either:

8b5bbbd9-235b-4183-94a3-d0bd6e1d3d4e-image.png

instead of:

8fd16d58-39b6-45f3-a24c-c4f941401cf3-image.png

like:
ff6291f2-6a01-4d33-866c-1f5c2019df89-image.png

and even a VPN User is required:

3397cc2b-5bbd-4e55-933a-bccc0f134c07-image.png

with:

a4585c69-0d7d-49a8-8bc9-792285643332-image.png

exactly where does the DNS (10.0.1.31) point?? this is the box itself or a separate DNS server on the network

You have to forward OpenVPN packets on your ISP router to the pfSense WAN IP. The pfSenes WAN address should be static.

Configuring an OpenVPN Remote Access Server

If your public IP from your ISP isn't static, you will have to use a dynamic DNS service to have a static FQDN, which you are able to connect to from outside.
The DDNS update should be done by the ISP router if possible. If it doesn't support that you may do it on pfSense, you can run a cron job with a short interval for that.

@careymichael I am having this same issue. When you said you had a static route pointed to the LAN interface, are you meaning in the firewall rules?

So uh... I totally disabled the VPN in order to be able to actually upload anything. Screenshot fail! Should be a little more enlightening here...
IMG_2374.jpg

Got it! Thanks so much for your help.

I've changed a dozen settings in the last couple of days so it's hard for me to say exactly what did it. The last thing I did before it started working was actually to uncheck the box that says "Force all client-generated IPv4 traffic through the tunnel." And now when I go back in, it shows checked again... hmmm.

In any case, it's working now and I hopefully won't ever have to do any troubleshooting ;) Thank you again for taking the time to help me.

Gertjan,

Thank you, I changed it to 192.168.9.0/24 and now things appear to be working!!

I'd tried that at one point but when I did the OpenVPN service wouldn't start for some reason, the log said something about a subnet mismatch (don't have log anymore) and I couldn't connect at all, when I brought it in to 192.168.0.0 the service would run.

Not sure what the problem was before but it's working now. Thanks again!

@gcu_greyarea

Ok danke schon mal für die Ausführliche Beschreibung der Möglichkeiten.

Das muss ich mal testen mit einer Failover Group (noch nie was mit gemacht) , kann man denn nur eine machen?

2 .Das kann man natürlich machen dann kann man halt einer gewissen Gruppe eine feste IP zuweißen, und wenn sich der Tunnel neu aufbaut gibt's halt ne neue Exit IP für alle innerhalb des Alias.

Das ließt sich so das man für eine vorgegebene Zeit einem Gateway zugeornet ist und der dann ein Zwangs Wechsel durchführt.

Das werde ich mal testen was der daraus macht bei ein paar IP check Seiten.

You need to push the IPv6 /64 as a route. It needs to be distinct from the tunnel network. I assume you have more than a /64 to use? /48 or /56?

Similar to how HE's TunnelBroker provides IPs, Unfortunately TunnelBroker does not work in this case because they Block CloudFlare (YES THEY FREAKING BLOCK CLOUDFLARE!!!).

Based on my experiences with HE over the years, if they did in fact block these sources, they have a good reason for doing so.

It is likely that your VPN interface isn't enabled in pfSense. Open Interfaces and select the VPN interface that you added to System > Routing > Gateways and click the Enable box. Click Save.

Navigate to Status > OpenVPN and restart the service. It should show a green check mark and show local, virtual, and remote host addresses.

In case this will help any one else, I've figured this out....

Here is a link on how to find the logs for NPS...

https://social.technet.microsoft.com/Forums/windows/en-US/45aa3000-c32b-483b-8d6e-565b56b163fc/how-to-check-the-nps-logs-in-the-event-viewer?forum=winserverNAP

Basically there are text file logs in c:\Windows\System32\LogFiles\In* , or you can check in Event Viewer under Diagnostics -> Event Viewer -> Custom Views -> Server Roles -> Network Policy.

In my case, the problem users were set to "Deny Access" under the "Dial In" tab of the user properties in AD Users & Computers. Setting to Allow Access fixed it up.

If you don't see the "Dial In" tab, this may be of help :

https://support.microsoft.com/en-ca/help/975448/the-dial-in-tab-is-not-available-in-the-active-directory-users-and-com

For me, I had to be on the server to get that tab, not accessing Active Directory Users and Computers on another PC.

Hope this will help someone else.

Thanks, Derelict for pointing me in the right direction!

СА на сервере -
0_1533291210606_Screenshot_3.png
ВПН сервера (с 1195 портом это тот который сейчас нормально работает на старом пфенсе а с 1190 тот который не могу завести
0_1533291294677_Screenshot_1.png
Клиент на новом пфенсе
0_1533291434217_Screenshot_2.png

Ok, final update.
Eliminated everything that had to do with this VPN, interface, rules, etc.

Started all over, following all the steps, and everything is working as it should, without the manual routes.

By the way, if you run into the routing problem, you can change the "Gateway creation" to BOTH or to IPv4 ONLY and apply/save ont both server and client side(!)

That creates the new route.

Thanks all for your time and effort