Messages

... also hat niemand eine Idee?

Hallo,

ich habe irgendwo mal gelesen, dass "multiple DNS" auf der Roadmap stehen oder zumindest für irgendwann angedacht sind.

Getrennte Netze verstehe ich, aber welche Vorteile erhoffst du dir durch eine DNS Trennung?

LG

Ok, also ich hab mir das über die "Paketaufzeichnung"s-Funktion mal angesehen.

Wenn ich am Quell-Host (172.16.128.1) einen Ping, Porttest oder sonst was über das Gateway (172.16.128.2) an das GW-Interface (192.168.2.1) sende, wird NICHTS aufgezeichnet ... da geht scheinbar nichts über das OpenVPN-Interface hinaus! und der Ping wird durch 127.0.0.1 beantwortet?

Wenn ich aber einen Ping vom GW-Interface (192.168.2.1) an 172.16.128.1 sende, kommt das Paket am richtigen Host an und der Reply kommt auch zurück!

NAT wurde für die betroffenen Schnittstellen keines definiert, siehe Screenshots im Anhang!

Welcher Mechanismus / welches Setting könnte bewirken, dass ein Host den ausgehenden PING selbst mit 127.0.0.1 beantwortet, wenn er selbst kein Interface oder VIP mit der Ziel-IP hat, obwohl er aber eine Route zu dem Ziel in seiner Table hat und die FW nichts blockiert?

Ich habe es auch mit einer VIP mit der Ziel-IP am Quell-Host versucht, um den gegen Check zu machen. Hier wird der PING klarerweise lokal beantwortet, jedoch steht dann die Ziel-IP im Reply und nicht die Loopback-IP.

Hier auch nochmal beide Routing-Tables:

von 172.16.128.1:

Code Select Expand


ipv4 172.16.128.0/24 link#7 U 968441 1500 ovpns4 LAN
ipv4 172.16.128.1 link#7 UHS 81 16384 lo0
ipv4 172.16.128.2 00:bd:a0:1c:ff:04 UHS 8311 1500 ovpns4 LAN
ipv4 192.168.2.0/24 172.16.128.2 UGS 9 1500 ovpns4 LAN
ipv4 192.168.3.0/24 172.16.128.2 UGS 0 1500 ovpns4 LAN
ipv4 192.168.4.0/24 172.16.128.2 UGS 6 1500 ovpns4 LAN



von 172.16.128.2 / 192.168.2.1:

Code Select Expand


ipv4 default 192.168.4.1 UGS 983880 1500 igb2 WAN
ipv4 127.0.0.1 link#4 UH 2166 16384 lo0
ipv4 172.16.128.0/24 link#8 U 973370 1500 ovpnc1 ULK
ipv4 172.16.128.2 link#8 UHS 0 16384 lo0
ipv4 192.168.1.0/24 172.16.128.1 UGS 0 1500 ovpnc1 ULK
ipv4 192.168.2.0/24 link#2 U 0 1500 igb1 Core
ipv4 192.168.2.1 link#2 UHS 0 16384 lo0
ipv4 192.168.3.0/24 link#1 U 3259080 1500 igb0 LAN
ipv4 192.168.3.1 link#1 UHS 0 16384 lo0
ipv4 192.168.4.0/24 link#3 U 985453 1500 igb2 WAN
ipv4 192.168.4.100 link#3 UHS 0 16384 lo0


Ich bin ehrlich planlos, was dieses Verhalten noch auslösen könnte!

Vielen Dank, für alle Ideen die eingebracht werden.

LG

Hat vielleicht noch jemand eine Idee, woran das liegen könnte?

Interessanterweise klappt das ganze, wenn ich den PING in verkehrter Richtung aussende.

Wenn ich am Ziel-Host, mit einem der Interfaces die sonst nicht erreichbar sind, einen Ping an den Quell-Host sende, schafft er es den Reply zurück zu senden.

Hier auch noch die Routing-Table vom Ziel-Host:

... der ICMP-Reply an 172.16.128.1 müsste über das gleiche Interface zurück gehen, wo der Request hergekommen ist!

Ja, das läuft problemlos!

... nur wenn ich versuche eine der anderen Interfaces zu pingen, ... geht es nicht über den OpenVPN Link, sondern wird lokal beantwortet.

Auf dem Quell aber auch auf dem Ziel-Host ist ICMP auch generell gestattet!

Dank dir für deine Hilfe!

Hallo,

nur begrenzt!

Es gibt 3 Portweiterleitungen von der externen IP auf interne Services, siehe Screenshot im Anhang.

Und 2 ausgehende Regeln, sofern die FW als Gateway ins Internet bzw ins "ULK" Netz verwendet wird (trifft in dieser Situation nicht zu!).

Virtuelle IP-Adressen sind keine definiert!

LG

Ich habe jetzt noch Versucht die Situation schematisch darzustellen. ... Vielleicht kann mir ja jemand mit einer Idee weiterhelfen!?

Code Select Expand



        WAN / Internet
            :
            :
            :
      .-----:-------.
      |  OPN:sense  |
      |  (Br:dge)   |
      '-----:-------'
            | 172.16.128.1/24
            |
            |
        LAN | OpenVPN
            |
            |
            | 172.16.128.2/24
      .-----:-------.
      |  OPN:sense  |  192.168.4.0/24
      |  (Br:dge)   +------------------------+> Default-GW / 192.168.4.1 ---> Internet
      '+----+-------'
       |    |
       |    |
       |    | 192.168.3.0/24
       |
       | 192.168.2.0/24



[127.0.0.1]

Hallo Leute,

ich habe 2 OPNsense Hosts über OpenVPN mit einander verbunden. Am 1sten (DMZ) habe ich einen OpenVPN-Server und NGINX reverse Proxy, am 2ten (OpenVPN-Client) mehrere physikalische Subnetze.

Für die Erreichbarkeit der Subnetze habe ich am ersten Host die OpenVPN - Client IP Adresse (172.16.128.2) als Gateway eingetragen und darauf die Subnetze (192.168. ... ) als Routen angelegt.

Vor dem Upgrade hat diese Konfig wunderbar funktioniert, wenn ich jetzt aber versuche am ersten Host einen PING auf ein Subnetz-Interface vom 2ten abzusetzen, bekomme ich folgendes:

PING 192.168.2.1 (192.168.2.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.079 ms

... der erste Host antwortet selbst auf den ECHO Request!???

Hier noch die Routing-Table vom ersten Host:

ipv4   127.0.0.1   link#2   UH   58014   16384   lo0       
ipv4   172.16.128.0/24   link#7   U   1459050   1500   ovpns4   LAN   
ipv4   172.16.128.1   link#7   UHS   69   16384   lo0       
ipv4   192.168.2.0/24   172.16.128.2   UGS   3   1500   ovpns4   LAN   
ipv4   192.168.3.0/24   172.16.128.2   UGS   0   1500   ovpns4   LAN   
ipv4   192.168.4.0/24   172.16.128.2   UGS   9   1500   ovpns4   LAN   

Wenn ihr eine Idee habt, woran das liegen könnte, wäre ich sehr Dankbar!

LG,
Mophi

Hi,

no, they don't!

But it is possible to assign the Interfaces with the CLI. Thank you "Mann-IT" for the hint!

I'm convinced, this is still a BUG in the GUI!

Kind regards,
Mophi

Hallo,

ich bin begeistert, über den Weg hat das tatsächlich funktioniert.

Vielen lieben Dank für den Tipp!

LG

... Ich halte das dennoch für einen BUG in der GUI!

Hi Bart,

thank you for your help, but that doesn't work for me!

I did your recommendation, added a VLAN with WAN as parent and assigned it as LAN-Interface (with prevent from removal).

Afterwards i wanted to assign one tap-Device as "VPN"-Interface, but when i push "+" the Device of LAN-Interface changes from VLAN-Device to the tap-Device, instead of creating a new Interface with the tap, which i wanted to define with name "VPN".

Do you have any other ideas?

Hallo,

ja es wäre denkbar, dass es am fehlenden physischen LAN-Adapter liegt.

Virtuelle-Adapter (auch reboot beständige) können wir ja erzeugen. Das VLAN am WAN Adapter bliebt bei einem reboot erhalten und lässt sich auch alternativ dem LAN-Interface zuordnen.

Die virtuellen OpenVPN-Adapter gehen bei einem reboot zwischenzeitlich verloren, aber die Schnittstellen-Zuordnung sollte persistent bleiben, was sie auch tut wenn man nur ein einziges tun/tap-zugewiesen hat bzw. mit "Lock - prevent interface removal" arbeitet.

Der Bug liegt wo möglich an der Stelle, wie mit Interface-Typen umgegangen wird. ... möglicherweise werden virtuelle Adapter bei der Schnittstellen-Zuordnung anders behandelt wie physische.

... Ich konnte nach wie vor keinen funktionierenden Workaround finden :( !

Hallo Mario,

vielen Dank für deine Nachricht! ... beruhigt mich zu hören, dass nicht nur mir so geht.

@all:
Ich habe jetzt auch einen englischen Eintrag dazu eröffnet um die Chancen auf einen Workaround oder Bug-Fix zu erhöhen: https://forum.opnsense.org/index.php?topic=9541.0

Falls jemand eine Idee hat, sie wäre willkommen!

LG,
Mophi