@bobby121418

As long as the ends have different addresses, within the same subnet, it should work. PfSense does that for you automagically. It assigns the first usable address to itself and subsequent addresses to the client(s). All you have to do is pick the subnet.

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

@mrDick гляньте тут - https://forum.netgate.com/topic/131401/%D0%BC%D0%B0%D1%80%D1%88%D1%80%D1%83%D1%82%D0%B8%D0%B7%D0%B0%D1%86%D0%B8%D1%8F-openvpn/75 настроено не по феншую, а переделать не получается. Но сколько лет работает на 3 офиса.

UPD по новым требованиям отключите сжатие и поставьте алгоритм на 512

UPD2 тьфу, забыл. Может уже и не актуально, но в Keenetic в ПЕРВУЮ ОЧЕРЕДЬ отрубите свой OpenVPN от других интерфейсов через CLI (там мануал есть в их хелпе), иначе эта пакость будет туннель пихать и в WI-Fi, даже если там гостевая сеть настроена!!!

Still following the thread I mentioned above, I saw that the eval previously was right before RESULT=.
I have tried to comment the if statement block and move eval, so this way

# eval serial="\$tls_serial_${check_depth}" # if [ -n "$serial" ]; then eval serial="\$tls_serial_${check_depth}" RESULT=$(/usr/local/bin/php-cgi -q /etc/inc/openvpn.tls-verify.php "servercn=$2&depth=$3&certdepth=$4&certsubject=$5&serial=$serial&co nfig=$config") if [ "${RESULT}" = "FAILED" ]; then exit 1 fi # fi

and I don't get anymore the error on the certificate!
I don't know if I need to open an issue about this.

However, now I get the error about the user authentication

SENT CONTROL [spike]: 'AUTH_FAILED' (status=1)

like I was getting when I set "Certificate Depth = Do Not Check".
I looks like I'm not the only one having this issue.

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

@stephenw10 I didn't realize that I was able to create an interface for VPN. I did that (and it booted the remote users, lol), and was able to configure the FTP Proxy Client plugin to work with it. Thank you for your help!

@benjaminpc said in PfSense AWS OpenVPN kein Internet:

Wenn ich mich aber nun via OpenVPN verbinde kann ich zwar die PfSense pingen aber nicht die Server im LAN Netz
Ebenso haben die Server kein Internet

Beide Symptome könnten hier dieselbe Ursache haben, aber auch verschiedene.
Ich würde die Internet Verbindung der VMs als erstes in Angriff nehmen. Scheint mir leichter zu klären zu sein.

Nachdem die pfSense aus dem Internet erreichbar ist und ihrerseits die Server erreichen kann, besteht mal "physisch" eine durchgehende Verbindung.
Ich nehme an, vom LAN ist nach wie vor alles erlaubt, also die standardmäßige any-to-any Regel aktiv.

Dann versuche mal von einer VM einen Ping auf 8.8.8.8. Wenn das funktionieren sollte, liegt es vermutlich daran, dass die VMs keine Hostnamen auflösen können.

Falls der Ping auch scheitert, könnte das Outbound NAT nicht funktionieren. Dann würde ich die Frage stellen, wie dein WAN konfiguriert ist. Wenn manuell, hast du in den Interface Einstellungen auch das Gateway angegeben?

@mdomnis I have since upgraded to 22.01 with FRR version 1.1.1_6. In my preliminary testing, the routes seems to be working closer to what is expected. I still have a weird issue where sometimes the neighbors don't like to peer fully and I have to force restart FRR, but from some quick tests, it looks like at least the route is being added to the table correctly. For now at least.

@mpcjames glad I could help.

@viragomann Dachte ich mir schon, ist aber ist trotzdem schade. Irgendwas ist immer, vor allem wenn etwas einfach umzusetzen ist. Das ganze funktioniert ja überraschend gut, nur das die IP-Adressen von der anfragenden Quelle nicht an den HAProxy weitergereicht werden.

@johnpoz

Yap! You are right... Some times we don’t think as it should be. It’s exactly the same situation that I’ve with the printer – just an IP assign and everything is working.

As far as I know, TrueNAS (before FreeNAS) has not any internal firewall. At least configurable with the GUI. I’ll investigate deeper.

Maybe it’s the gateway (I’ve some doubts that is wrong), so I’ve to confirm.

For testing, I’ll also change the NAS to the LAN (same net where I’ve also the pfSense) and check if anything changes.

@romanvekil said in pfSense OpenVPN on VPS client not access internet:

here wireshark listening vpn interface form pc when connected

Would like to know if you can see these packets on pfSense OpenVPN interface likewise. I suspect, you can't.
In this case, I'd recommend to tear down the OpenVPN server and start from scratch.
Have read some threads here in the past, where people complaining similar issues and never got it working.

@benjaminbeckcsl
Ohne Konfiguration ist das echt schwer

@anthoinn Problem resolved just need to put correct subnets on server side

@nick-loenders
Yes, this simply adds the proper route on the client to go over the VPN gateway.

@3lmar It turned out it was a totally different problem.
The solution is somehow related to pfsense, because I would not have found it without pfsense's package capture.
My windows 10 notebook on the OpenVPN was trying to connect via port 80, which seemed strange. I learned it did that, because the share wasn't on the same subnet.
The solution was to disable NetBIOS over TCP/IP: https://docs.microsoft.com/en-us/troubleshoot/windows-server/networking/direct-hosting-of-smb-over-tcpip

Sorry for having disturbed you.
Maybe this helps anybody else, who like me wouldn't expect a problem with windows pcs connecting to windows pcs.
I should have stayed with linux.

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

@johnnyfive Yeah this is the problem - what a shame. It would be really great to have full acceleration using QuickAssist!

Somebody please?

@mainzelman Thanks for the reply.

Site B IPSec firewall rules were empty (I assumed this to be ok because Site A and Site B hosts can talk no problems)

I added the rule for Site B and it appears to be now working!
dd6e54f6-fa74-4b38-bf03-a8b3e6c04ec9-image.png

I knew it had to be something simple I missed, thank you!

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?

@viragomann thank you for the suggestion, I am gonna give it a try, we should fix the issue by having the remote endpoint add a phase 2 for the openvpn subnet but in the meantime this should fix it as well.

Thank you very much! Your solution fixed my problem! I missed to add the tunnel network to the remote networks on site B.

IMO it's impossible to tell active directory domain member to not look for dns record of domain name.

Hey there,
I think the problem is not within the Router but in the testserver.

Even though I did a reinstall recently and never installed anything else than apache2 and openssh-server, a tcpdump confirmed that the packets arrive at my testserver but my testserver does not respond to them for whatever reason. So most probably my fault.

Anyway

Thank you @Rico !

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

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