Messages

Hey,

schließe mich meinen Vorrednern an: das macht man am Besten einmal in Papierform beim Erstellen bzw. Aushändigen des VPN Zugangs an den Kunden.
Der Kunde klickt die LandingPage eh spätesens nach dem zweiten Mal sofort weg, weil er es bereits gelesen hat nur dann nur noch nervt.

Trotzdem habe ich das mal bei mir probiert. Anscheinend kann das Captive Portal nicht auf eine OpenVPN Verbindung gelegt werden. Sobald ich das Interface dafür auswähle erhalte ich die Meldung "error reloading captive portal template".
Was mir beim Test auch aufgefallen ist: wenn ich der FW Regel die den Traffic nach der LandingPage erlauben soll ein Gateway mitgebe, funktioniert die LandingPage nicht mehr. Der User bekommt dann sofort die komplette Freischaltung.

Jas Man

So auf den ersten Blick hätte ich gesagt "Dreh mal die 'Maximum Table Entries' hoch".
Aber da bist Du ja schon selbst drauf gekommen.  :)

- Hast Du das Problem auch, wenn Du jetzt einen neuen Alias anlegst?

- Ging es vorher und nach einem Update nicht mehr?

- Im Alias selbst für z.B. die vertrauenswürdigen Geräte sind aber alle Hosts weiterhin eingetragen, nur unter pftables siehst Du dann nur einen? Dann könnte man vermuten das irgendwo ein "böses" Zeichen oder so drin steht, und der beim Laden der Aliase irgendwo abbricht. Das sollte dann aber in den System Logs stehen.

Hey,
steht was in den Logs unter System: Log Files: General was auf ein Problem mit den Alias hinweißt? Hast Du vielleicht ein Leerzeichen am Anfang oder Ende der URL? Kannst Du die URLs im Browser aufrufen?

Hab es auch nach der Anleitung eingerichtet und es funktioniert ohne Probleme.

Gruß
Jas

The routing table looks fine. If any routing protocol is active which share a route for 192.168.3.x/yy between the providers router and your OPNsense, you should see this route in the table.

• Run a traceroute from the GUI (Interfaces: Diagnostics: Trace Route) on OPNsense_Site1 to LAN_Site3 interface or client with source interface LAN_Site1 (192.168.1.254).
  
  
  
  • Is the result fine? Then I guess the problem is not the OPNsense. It must be something in the LAN or the routing table of the clients are misconfigured.
  • Runs it to the WAN interface as the traceroute from the clients?
• Run a traceroute from a client of LAN_Site1 to the OpenVPN interface of Site3 (192.168.254.6).
  
  
  
  • Is the result fine?
  • Runs it to the WAN interface as the traceroute to LAN_3?
• In your first post the traceroute to LAN_2 shows the IP 192.168.254.14. You wrote that this is the OpenVPN interface for Site_1 <-> Site_2 tunnel. But according on your routing table this is the OpenVPN interface for LAN_5. Is this just another subnet on Site_2, or do you have additional tunnels and you only mistaken/obfuscate the IP? I think this is not really important for troubleshooting, but to understand your topology.
  
• I'm not very familiar with the Multi WAN function, but maybe this is the root of your issue. Can you disable this option or at least the additional lines? Then test again.
  
• Are you allowing communications between LAN_2 and LAN_3? If yes, can you reach clients from LAN_2 in LAN_3 and vice versa?
  
• Check your Firewall rules, especially those for LAN_3. Have you defined a gateway which forces 'policy based routing'?
  

Schön das es jetzt geht, aber sauber ist das glaub noch immer nicht.

Natürlich muss der eingehende Weg auch der ausgehende Weg sein. Den sonst sollte die Firewall die ausgehenden Pakete blocken weil er gar keine Session dazu kennt.

Und: wenn Du über Deinen DSLer rausgehst und somit die Source der Pakete die dynamische IP des DSLers ist, geht die Antwort zu diesen Pakten von z.B. OLDMAN ja auch an die dynamische IP Deines DSLers gehen. Sobald das Paket an Deiner OPNsense vorbei sagt die sich "Hey, das bin ich ja selbst", versucht es zu verarbeiten und da keine Session dazu existiert wird es verworfen. Ich denke das ist das eigentliches Problem. Und Du umgehst es jetzt nur, indem Du die Antworten einfach über ein anderes Gateway raus schickst.
Ist aber nur ne Vermutung. Dazu kenne ich den Aufbau nicht gut genug.

Uhhh, so langsam verliere ich echt den Überblick  :)

Du hast Recht, bei den Port-Forward-Rules gibt es kein Logging, zumindestens nicht auf der GUI. Ich war bei den Outbound Regeln.

Noch mal zur Source IP: welche Adresse siehst Du denn in den Firewall Logs als Source, wenn Du über Deinen DSLer mit der dynamischen IP den Server OLDMAN über die statische IP bei feste-ip.net erreichen willst? Die dynamische DSLer IP oder die statische IP von feste-ip.net?

Das es nur bei den VMs nicht funktioniert ist wirklich komisch. Aber wenn die selbe Regel bei BareMetal Systemen funktioniert kann es ja nur noch an der VM Umgebung liegen. Vorausgesetzt die BareMetal Systeme mit denen Du getestet hast hängen im selben Subnetz wie die VMs.
Aber außer dem üblichen Kram (Subnetmask oder Gateway Adresse bei den VMs falsch) fällt mir gerade auch nix ein. Können die VMs denn ins Internet pingen oder surfen? Nicht das die einfach keine Rückroute haben.

Zum HAProxy kann ich Dir leider nix erzählen, den habe ich auf der OPNsense noch nicht eingerichtet. Steht noch auf der ToDo Liste :)

Hey,

der Source Port 56900 ist ja der Client Port, also der Port mit dem der Client die Verbindung zu Dir aufbaut. Der ist für Dich irrelevant.
Das Du als Source Deine eigene, externe feste IP Adresse siehst und nicht die Quell-IP des eigentlichen Besuchers wird vermutlich daran liegen, dass der Anbieter die Pakete zu Dir weiterleitet. Oder versuchst Du vielleicht dich selbst über Deinen Anschluss zu erreichen? Dann könnte asynchrones Routing das Problem sein. Versuch in diesem Fall einfach mal über einen anderen Anschluss (z.B. Mobilfunk) die URL zu erreichen.

....
ich bin mir zwar nicht sicher wo der Unterschied zwischen der normalen und einer "linked rule" ist. Aber wenn ich beide auf NAT Rule setze geht nichts mehr.

Was meinst Du mit "beides auf NAT Rule setzen"?

Hast Du mal das Logging für die NAT Rule aktiviert um zu kontrollieren, ob der Traffic auch über die korrekte Regel abgearbeitet wird?

Jas

Have you checked if there's a typo in a subnetmask of one or more interfaces?
Could you post your routing table?

Strange problem....but I like to solve it  ;)


EDIT: I'm still thinking about the traceroute and the WAN IP that appears as first address. Is there an active NATting rule on the LAN interface which could be the reason for this?

So habe ich es auch von Anfang an verstanden und wollte es auch so einrichten. Nur habe ich keine Ahnung wie ich die drei Phase2 Settings der Fritte mitgebe.

In der Config gibt es nur eine Phase2 und wenn ich den Part einfach kopiere und noch mal dran hänge, nimmt sie nur den letzten Eintrag.

Hey cmu,

Danke schon mal für den Hinweis mit dem clonen der Phase2 Einträge.

Bei den Subnetzen verhält es sich aber genau anders herum: ich habe drei Subnetze an der OPNsense, und nur eins an der Fritz!Box. Aus dem Netz der Fritte will ich die drei Netze an der OPNsense erreichen.
OK, ich werde vermutlich weiterhin drei Phase2 Einträge auf der OPENsense für die Subnetze benötigen?! Aber wie sieht die Config auf der Fritte aus? Benötige ich drei VPNs oder packe ich das alles in eine Konfiguration? Wie muss diese dann aussehen?

Gruß
Jas

[Fritz!Box 6590]

Hi,

ich habe einen IPsec Tunnel zwischen meiner OPNsense und einer Fritz!Box 6590 aufgebaut. Der Tunnel läuft stabil, gute Performance, alles super.

Nun möchte ich aber aus dem LAN der Fritz!Box mehrere Subnetze auf meiner OPNsense erreichen. Und da komme ich nicht weiter. Hier mal die Eckdaten:

Fritz!Box 6590
LAN: 192.168.0.0/24
WAN: öffentliche, dynamische IP (DynDNS vorhanden)

OPNsense
LAN1: 192.168.1.0/24
LAN2: 192.168.2.0/24
OpenVPN: 192.168.3.0/24
WAN: öffentliche, dynamische IP (DynDNS vorhanden)

Mein Wunsch ist alle drei Subnetze aus dem LAN der Fritte zu erreichen, und das möglichst mit nur einem Tunnel.
Was ich bereits probiert habe:

• Drei VPNs auf der Fritte eingerichtet mit identischer Phase1, und mit angepasster Phase2 für das jeweilge Remote Subnetz der OPNsense. Auf der OPNsense habe ich dann einen VPN Tunnel mit jeweils einer Phase2 für jedes Subnetz angelegt


• Drei Tunnel (für jedes Subnetz einen) auf beiden Seiten mit den selben Einstellungen in Phase1, und mit angepasster Phase2 für das jeweilge Remote Subnetz


• Drei Tunnel (für jedes Subnetz einen) auf beiden Seiten mit den unterschiedlichen PSK Keys und ID Einstellungen in Phase1, und mit angepasster Phase2 für das jeweilge Remote Subnetz

Bei allen Varianten geht aber immer nur ein Subnetz online. Ich hab es einmal geschaft zwei Subnetze online zu bekommen. Aber ich weiß nicht warum und weshalb...... :-[

Bekommt man überhaupt mehrere Subnetze über die Fritte mit nur einem VPN/Tunnel geschaltet (mehrere SAs), oder muss man zwangsweise für jedes Subnetz einen Tunnel aufbauen?

Hat das schon mal einer hinbekommen?

Thanks.

Jas

Hey,

It's not totally clear what you want to do. Would you like to set up an VPN to dial-in into your network for managing your devices? Or would you like to manage them without VPN? What do you mean wit manually and automatically? What should be the trigger for automatically?

In generally Wake-On-Lan is possible if your devices support WOL.
You can create an VPN to get access to your LAN. Then you can manage your device like you're connected to your LAN directly.

If you want to wake them up over the Internet (whitout VPN), you must configure a port forwarding rule for the WOL magic packets to your LAN.
Create an static ARP entry for an free LAN IP e.g. 192.168.1.10 with the broadcast mac address FF:FF:FF:FF:FF:FF. Forward the WAN WOL magic packets to this address, so that the packet will be broadcasted to your LAN. That means every device will receive this packet, but only the device with the mac addess of the magic packet will wake up.

To power off the devices there's no way like WOL, as far as I know. If you've an management app or something like this for them, you can shut them down remotly. But for this I would suggest the VPN solution.

Jas

Hey,

wenn Du in den Firewall Logs des LAN Interface erlaubten Traffic für den Verkehr OpenVPN:8001 -> OLDMAN:5001 siehst, muss die Regel ja funktionieren. Hast Du mal das Logging in der NAT Regel aktiviert um das sicherzustellen?

Sitzt OLDMAN im selben Subnetz wie die 192.168.1.23? Wenn ja würde das bedeuten, dass der Rückweg funktioniert da die 192.168.1.23 ja funktioniert. Wenn nein, würde ich mal den Rückweg prüfen.

Ist der Alias OLDMAN noch korrekt? Es gibt ein Problem in der aktuellen Version, dass wenn man den Alias nachträglich anpasst, die NAT Regeln das nicht sauber übernehmen. Ich glaub das ist aber nur wenn man den Alias Namen anpasst, nicht die Inhalte des Alias.

Was mir noch aufgefallen ist: die OLDMAN NAT Rule zeigt das Zeichen für eine "linked rule" (doppelter Pfeil), die 192.168.1.23 NAT Rule nur das normale Zeichen. Ich hab keine Ahnung wo genau der Unterschied da liegt, aber vielleicht hat es was damit zu tun.

Gruß
Jas

Dann musst Du nur den Port 563 mit Source NAS und Destination Internet auf dem LAN Interface der OPNsense freigeben. 

Ein Reverse-Proxy wäre nur für den umgekehrten Fall, also ein Verbindungsaufbau von Extern nach Intern notwendig bzw. sinnvoll.

Was @mimugmail glaub wissen will: baut die NAS eine Verbindung/ein Tunnel nach Extern auf, oder wird eine Verbindung/ein Tunnel von Extern zur NAS aufgebaut?