Messages

Hey,

ich verwende interne ULA-Adressen (fd00::) und baue daraus ein sauberes NAT nach draußen.

Das NAT ist IPv6 (public) auf IPv6 (private fd00::1).
Das wird soweit von der OPNSense unterstützt. Zumindest wenn ich manuell im Portforwarding die Public-IP/128 auswähle unter "Einzelner Host / Netzwerk". Nehme ich direkt die Virtuelle IP, wie ich diese angelegt habe, wird diese als /32 angelegt. Das führt zu interessanten Phänomenen, wie das Loopback auf den eigenen Mailserver, wenn über IPv6 versendet wird.

Ich würde auf einen Fehler in der WebGUI tippen, dass dort eine fehlerhafte Netzwerkmaske ausgelesen wird. Die VIP hat die Netzmaske /128. In der Forwarding-Regel steht nach dem Speichern bei der VIP/32, obwohl es sich um eine IPv6-Adresse handelt. Daher wird der Traffic ausgehend dann auf sich selbst bei /32 umgeleitet. Es sollte dort die korrekte Netzmaske /128 automatisch anstelle von /32 dort stehen.

Viele Grüße
Lars

Hallo,

ich habe unter Schnittstellen -> Virtuelle IPs mehrere öffentliche IPv6-Adresse im CARP angelegt. Später bei der Konfiguration des Portforwarding (Firewall -> NAT -> Portforwarding) wähle ich diese IPs aus und erhalte eine falsche Subnetzmaske (/32) anstelle von /128. Daher kommt es zu Problemen beim Routing, da z.B. der Mailserver (TCP 25) mit /32 angesprochen wird, lande ich wieder bei meinem eigenen mit der Meldung "mail for <external host> loops back to myself".

Die öffentliche IP wird als Ziel angegeben und bei Ziel-IP-Umleiten eine lokale IPv6.

Workaround:
Anpassen von der Virtuellen IP auf "Einzelner Host / Netzwerk" und die Subnetzmaske auf /128 ändern.

Viele Grüße
Lars

The problem is the vhid in the virtual ip.
Every Firewall-Cluster have the same vhid in our dmz-vlan. I changed the vhid of one firewall-cluster and it works.

Hallo zusammen,

der Fehler wurde heute gelöst. Ursache ist das die VHID der virtuellen IPs in dem gleichen VLAN mehrfach vergeben waren. Dadurch gab es massive Probleme.

VG Lars

>> Beim zweiten Firewall-Cluster (in der DMZ zu den internen Netzen) kann das ausgehende NAT nicht auf die 192.168.0.160/24 festgelegt werden.

>Hier fehlt das "WARUM". Es kann natürlich darauf festgelegt werden, sollte es auch. Wenn das nicht geht, fehlt hier wie gesagt, das Warum.

Das NAT kann darauf festgelegt werden. Es kommt beim Ping von 192.168.0.160 auf die 192.168.0.150 (ICMP erlaubt) zu einem großen Paketverlust (60-80%). Testweise habe ich eine größere Webseite einer Zeitung aufgerufen und dort nur halbe Bilder dargestellt bekommen.

>> Ich möchte in dem zweiten Cluster die VIP vom ersten Cluster als Gateway definieren. Dabei geht trotz Any nach draußen kein Ping zu 1.1.1.1 oder 8.8.8.8

>Du möchtest was genau? Die beiden Nodes von Cluster 2 (also dem internen), sollen als GW die .150 haben? Oder? Das wäre der korrekte Weg, dass beide Nodes als WAN GW die .150 bekommen, die ja redundant auf dem Border Gateway Cluster liegt. Auch hier wieder "WARUM" und was geht nicht?

Beim ersten Cluster gibt es zeitweise bereits Aussetzer beim Schwenk der virtuellen IPs (keine Antwort vom ersten Cluster). Diese Aussetzer in der Zuständigkeit auf das zweite Cluster scheinen zuzunehmen, da von 10 Pings unterschiedlich viel zurück kommt. Auf beiden Synchronisationsschnittstellen (HA) gibt es eine ANY-allow-Regel.

Auszug des Ping-Verlustes über das erste Cluster (VM hat die 192.168.0.100 und geht über die 192.168.0.150 ins Internet). Das NAT ausgehende NAT steht auf der öffentlichen VIP. Die Firewall selbst macht ein Loadbalancing bei Paketverlust oder hoher Latenz auf die zweite Leitung. Das Loadbalancing funktioniert, da die Gateway-Gruppe in den Regeln mit angegeben ist.

Code Select Expand


PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=36 ttl=58 time=8.22 ms
64 bytes from 1.1.1.1: icmp_seq=37 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=38 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=40 ttl=58 time=8.11 ms
64 bytes from 1.1.1.1: icmp_seq=44 ttl=58 time=8.71 ms
64 bytes from 1.1.1.1: icmp_seq=46 ttl=58 time=8.20 ms
64 bytes from 1.1.1.1: icmp_seq=48 ttl=58 time=8.17 ms
64 bytes from 1.1.1.1: icmp_seq=50 ttl=58 time=8.27 ms
64 bytes from 1.1.1.1: icmp_seq=52 ttl=58 time=8.24 ms
64 bytes from 1.1.1.1: icmp_seq=53 ttl=58 time=8.37 ms
64 bytes from 1.1.1.1: icmp_seq=54 ttl=58 time=8.08 ms
64 bytes from 1.1.1.1: icmp_seq=55 ttl=58 time=8.15 ms
64 bytes from 1.1.1.1: icmp_seq=56 ttl=58 time=8.02 ms
64 bytes from 1.1.1.1: icmp_seq=57 ttl=58 time=8.39 ms
64 bytes from 1.1.1.1: icmp_seq=58 ttl=58 time=8.19 ms
64 bytes from 1.1.1.1: icmp_seq=59 ttl=58 time=8.23 ms
64 bytes from 1.1.1.1: icmp_seq=60 ttl=58 time=8.12 ms
64 bytes from 1.1.1.1: icmp_seq=61 ttl=58 time=8.13 ms
64 bytes from 1.1.1.1: icmp_seq=62 ttl=58 time=8.16 ms
64 bytes from 1.1.1.1: icmp_seq=63 ttl=58 time=7.99 ms
64 bytes from 1.1.1.1: icmp_seq=96 ttl=58 time=8.41 ms
64 bytes from 1.1.1.1: icmp_seq=97 ttl=58 time=8.16 ms
64 bytes from 1.1.1.1: icmp_seq=98 ttl=58 time=8.17 ms
64 bytes from 1.1.1.1: icmp_seq=99 ttl=58 time=8.10 ms
64 bytes from 1.1.1.1: icmp_seq=100 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=110 ttl=58 time=8.19 ms
64 bytes from 1.1.1.1: icmp_seq=112 ttl=58 time=8.14 ms
64 bytes from 1.1.1.1: icmp_seq=114 ttl=58 time=8.20 ms
64 bytes from 1.1.1.1: icmp_seq=116 ttl=58 time=8.22 ms
64 bytes from 1.1.1.1: icmp_seq=118 ttl=58 time=8.31 ms
64 bytes from 1.1.1.1: icmp_seq=119 ttl=58 time=8.27 ms
64 bytes from 1.1.1.1: icmp_seq=120 ttl=58 time=8.05 ms
64 bytes from 1.1.1.1: icmp_seq=121 ttl=58 time=8.17 ms
64 bytes from 1.1.1.1: icmp_seq=122 ttl=58 time=8.39 ms
64 bytes from 1.1.1.1: icmp_seq=123 ttl=58 time=8.22 ms
64 bytes from 1.1.1.1: icmp_seq=124 ttl=58 time=8.16 ms
64 bytes from 1.1.1.1: icmp_seq=125 ttl=58 time=8.44 ms
64 bytes from 1.1.1.1: icmp_seq=126 ttl=58 time=8.61 ms
64 bytes from 1.1.1.1: icmp_seq=127 ttl=58 time=8.21 ms
64 bytes from 1.1.1.1: icmp_seq=128 ttl=58 time=8.19 ms
^C
--- 1.1.1.1 ping statistics ---
151 packets transmitted, 40 received, 73% packet loss, time 152554ms
rtt min/avg/max/mdev = 7.992/8.223/8.712/0.167 ms


Die Kundenumgebung hat in der kleinen Darstellung zwei 10GB-Switche, die jweils direkt am Core-Switch hängen. Vom Core-Switch gehen weitere Switche in unterschiedliche Räume ab. Ich beschränke die Netzwerkkomponenten auf die genutzten Komponenten. Als Switch-Hersteller ist D-Link im Einsatz.

Die gesamten Firewalls sind in einem Proxmox VE-Cluster von 5 physikalsichen Maschinen verteilt. Die Netzwerkkarten stehen auf virtio. In der Zwischenzeit habe ich das Phänomen versucht in einem kleinen Nachbau nachzustellen. Dafür habe ich zwei Desktop-Rechner genutzt, die zwei Netzwerkkarten haben und eine Linkbündelung auf den Switch verwendet.

In der Kurzform habe ich das so aufgebaut:
PVE - Switch - Switch - PVE
   |
Uplink zum Internet (mit VIP); Anschluss an die restliche Umgebung!

Das PVE-Management VLAN ist untagged und die restlichen VLANs sind als tagged konfiguriert. Die Switche und die PVEs sind in einem abgetrennten Netzwerkbereich und der einzige Übergabepunkt ist die VIP ins Internet.

>> Bei der Leitung A liegen ca. 16 public IPs, die jetzt über das erste Firewall-Cluster ins DMZ-Netz geroutet werden sollen (ausgehendes NAT für div. Server).

> Wenn die IPs aufliegen (also gleiches Netz wie die Firewalls haben und nicht per Routing auf die Firewall Adresse kommen) dann wird da nichts weitergeroutet, sondern du kannst die Adressen nur als VIP Alias definieren und diese dann per 1:1 NAT o.ä. weiterdefinieren.

Das ist mir klar und ist der gleiche Weg, den ich mir überlegt habe. Alternativ geht dort anstelle eines 1:1-NATs die Portweiterleitung und ein entsprechendes ausgehendes NAT.

I have a Multi-WAN with two internet connections. The first one is a fibric, connected to the first Switch. The second one is a VDSL. The fabric have some virtual (public) IP-addresses. The OPNsense is working in a Cluster of 2 Nodes. The Cluster is connected in our DMZ-Network and have 1 virtual IP.

We provide a second Cluster for the internal Traffic for our environment. Every network gets a smaller Subnet of 10.0.0.0/8 Network in one VLAN (e.g. 10.1.1.0/24).

I have Routing Problems to connect the second Cluster with the virtual IP 192.168.0.160 to the first Cluster 192.168.0.150. I check the first Cluster with one PC in the DMZ an I have a good connection with one or two pings failed.

I check the second Cluster with the same PC in another Subnet (no blocking everything), I get only one or two pings back from 1.1.1.1 or 8.8.8.8.

Version OPNsense: 19.7.6

If I create in the second Cluster a Gateway-Group with the real IPs of OPNsense in the first Cluster, I will get every response. If I use the virtual IP of the first Cluster, I get one or two responses (10 ICMP-Requests). What is the problem?

Grettings
Lars

Code Select Expand


        WAN                   WAN
         :                     :
         : Ethernet            : VDSL
         :                     :
:               -----------
         :               |  Router  |
         :               ------------
         :                     |
         -----------------------
         |  Switch (redundant) |
         -----------------------
           |                 |
           |                 |
           |                 |       Multi-WAN with Backup
      -----------      -----------
      | OPNsense |-----| OPNSense|
      ----------- HA-1 -----------
           |     CARP        |
  x.x.x.151|  VIP x.x.x.150  | 192.168.0.152/24
           ---------------------
           |       DMZ         |
           ---------------------
           |    CARP         |
  x.x.x.161|  VIP x.x.x.160  | 192.168.0.162
     -----------          -----------
     | OPNsense |---------| OPNSense |
     -----------  HA-2    ------------
         |                   |
         |                   |
         ---------------------
         |  Internal Net VIP |
         ----------------------


Hallo zusammen,

ich habe an dem ersten HA-Cluster ein Multi-WAN. Leitung A ist eine Glasfaserleitung (wird auf dem Switch gewandelt) und Leitung B eine VDSL-Leitung (Router vorgeschaltet, arbeitet im Privaten Adressbereich).

Bei der Leitung A liegen ca. 16 public IPs, die jetzt über das erste Firewall-Cluster ins DMZ-Netz geroutet werden sollen (ausgehendes NAT für div. Server). Dafür habe ich eine virtuelle IP (CARP) angelegt und die OPNSense im ersten Cluster kann nach draußen ohne Probleme kommunizieren.

Beim zweiten Firewall-Cluster (in der DMZ zu den internen Netzen) kann das ausgehende NAT nicht auf die 192.168.0.160/24 festgelegt werden. Wird dort die Schnittstellenadresse verwendet, ist das Lauffähig, kommt dem HA-Gedanken nicht wirklich nach, außer ich definiere eine Gateway-Gruppe.
Gerade im Hinblick auf die verschiedenen Netze, die in der DMZ stehen werden, z.B. über CARP weitere VIPs definiert, kommt es zu Problemen.

Ich möchte in dem zweiten Cluster die VIP vom ersten Cluster als Gateway definieren. Dabei geht trotz Any nach draußen kein Ping zu 1.1.1.1 oder 8.8.8.8

Version: 19.7.6

Code Select Expand


        WAN                   WAN
         :                     :
         : Ethernet            : VDSL
         :                     :
:               -----------
         :               |  Router  |
         :               ------------
         :                     |
         -----------------------
         |  Switch (redundant) |
         -----------------------
           |                 |
           |                 |
           |                 |       Multi-WAN mit Ausfallleitung
      -----------      -----------
      | OPNsense |-----| OPNSense|
      ----------- HA-1 -----------
           |     CARP        |
  x.x.x.151|  VIP x.x.x.150  | 192.168.0.152/24
           ---------------------
           |       DMZ         |
           ---------------------
           |    CARP         |
  x.x.x.161|  VIP x.x.x.160  | 192.168.0.162
     -----------          -----------
     | OPNsense |---------| OPNSense |
     -----------  HA-2    ------------
         |                   |
         |                   |
         ---------------------
         |  Interne Netze VIP |
         ----------------------