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

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.

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?