@viragomann said in OpenVPN Client Mode Zugriff Lokaler Webserver: Nein, die Clients müssen ohne Gateway auf den Webserver kommen. Dann musst du für diese Verbindung eine eigene Regel definieren, die kein GW erzwingt. Also Quelle: LAN net, Ziel: Webserver und diese Regel oberhalb der anderen positionieren, damit sie auch angewandt wird. Grüße Genau diese Regel hat in meiner Konfiguration gefehlt. Vielen Dank nochmal an alle Beteiligten für die Lösung meines Problems.

Thank you for your reply. When I check the widget, it only shows me the default gateway WAN_DHCP and does not show the openvpn gateway as a choice.

No there were not. I have deleted everything related to the RoadWarrior Server now and recreated it with another cipher, but same settings/TunnelNetwork/Buffer/Rules. It seems to work now. Could it be that pfSense sometimes doesn't activate rules unless you recreate them? It felt like that, though I dont really know why it didn't work and now works.

I was talking about the rules on pfSense, of course. As mentioned, such traffic must not be handled by floating rules. I don't know if you've set up some. You may also do a workaround with an SNAT rule for that traffic on the Debian system to get the routing work. But maybe that's not the best solution.

@rico Thanks will take a look

Everything depends on your setup. Would need more details. Post a network map. Are your VLANs terminated on PFsense or your switch? Post your server1.conf What are the IP's in the VLAN you're trying to access? What do the rules look like on your LAN and OpenVPN tab?

You can't use subnets contained inside your VPC subnet anywhere but the VPC itself. Use something outside of that for the other side of the VPN. Sorry. That's just the way AWS works, as you can see from that error message.

Bei der NAT Regel könntest du statt tcp/udp/* gleich ganz "*" any Protocol nehmen. Wird mit Sicherheit einfacher sein. Aber im Prinzip hat sich diese Lösung - durchaus korrekt - schon beim Lesen deines ersten Posts angedeutet, wenn du schriebst, dass du 403 Forbidden oder Logins wie von extern bekommst. Viele IoT oder andere Lösungen erkennen ihr eigenes Netz/LAN und nehmen für alles andere dann an, dass hier entfernter Zugriff bzw. Logins der Fall ist. Hier müsstest du case-by-case nachsehen, wo du ggf. zusätzliche interne Netze definieren kannst, damit die Anwendung/Lösung das VPN Netz als lokal/LAN erkennt. Mit der erstellten NAT Regel bist du aber hier noch einfacher unterwegs und wirst einfach mit der IP der pfSense intern gemappt, was die Geräte dann zufriedenstellen wird (wenn du eine besser nachverfolgbare IP brauchst, ist es kein Problem eine zusätzliche Alias IP auf die Sense zu nehmen und diese als interne NAT Adresse zu nutzen). Grüße Jens

How would you route traffic without adding some kind of router to this LAN? -Rico

Two things that I forgot to mention are that I already have OpenVPN set up successfully for my normal network and that since I'm new to the pfSense concept, I've never worked with VLANs on it before. I do, however, understand the VLAN broad concept since I've taken a Principles of Networking class as a computer systems administration student at my university.

Even in the logs, I can see that the server is pushing its own address as the gateway, yet pfSense does not use it as the gateway IP: Dec 21 02:45:36 openvpn 67745 PUSH: Received control message: 'PUSH_REPLY,route-gateway 172.27.120.1,topology subnet,ping 10,ping-restart 120,ifconfig 172.27.120.2 255.255.255.0,peer-id 0,cipher AES-256-GCM'

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.

@treborjm87 I'd be curious about this as well... I think you need to establish how much throughput/bandwidth you need and how many concurrent user connections you anticipate, etc? (Is this box dedicated to routing and VPN only or more exotic use cases like running VMs, etc) I've seen some charts floating around with hardware recommendations based on required throughput here and at the servethehome website.

Yes I know, AES-128-CBC was the maximum Speed for my SG-3100. -Rico

...this is what I already told you 2 days ago. -Rico

Hi DotDash, Thanks for your speedy reply. This is a shame, i must have missed that part during the googling sessions. I guess I'll look into getting a higher clocked speed AES-NI Intel Chip instead :) Cheers, AlienX

Thanks for sharing gateway settings

@rico I had a similar issue. Thanks for your advice!!

If you have only a "private" RFC 1918 address, then you're out of luck. To set up a VPN, you need an address that you can reach from elsewhere. Those private address won't work for that.

I wouldn't worry about it. Any Internet-facing port that's opened is going to be continually "under attack." But that's largely why things like OpenVPN exist. If you're getting these connection attempts non-stop, then yes I might worry that you are being specifically targeted. But odds are it's just the constant, random scanning for open ports with unsecured services behind them. I run an OpenVPN server on pfSense too and get connection attempts like these relatively frequently too.

@pnunn The default route is simply the way out of the network. It's just like driving somewhere. The first thing you have to do is get out of your driveway. On more complex networks there may be other, more specific routes that might be used first, but eventually you'll need a default route. The only exception is at the top level, between ISPs, carriers, etc., where every possible route must be known and the packet gets dropped if there isn't a route. You could route through an interface, but only on point to point links. On Ethernet, there's always the possibility of more than one other NIC out there, so you can't rely on using just the interface.

@grimm-spector Exactly, it will work just fine :)

@boxofrox Ah! <Sound of penny dropping, lightbulb turning on, forehead slap> Thank you, I forgot about the “certificate granting” part of a CA. What do you call it when you’re too young for a “senior moment” and too old for a rookie mistake? ;-) Salaam, kudos, thanks!

@medikopter said in OpenVPN TLS Fehler: Das klingt ja eigentlich ganz cool und simple, allerdings scheitere ich schon an der Umsetzung eines Failover. Nunja, aber das sind ja auch zwei verschiedene paar Stiefel ;) VPN auf beiden Interfaces zum Laufen zu bringen ist wesentlich leichter, weil du nichts umschalten/routen/sonstwas musst. Daher überhaupt nicht schwer. Also das er das Interface automatisch wechselt wenn eins Down ist. Es genügt doch eine Gateway Gruppe zu machen und die bei den Regeln auf dem LAN einzusetzen?