2.5.2-Beta: Test für MultiWAN Problem

JeGr

Moin,

hatte jemand von euch das MultiWAN Problem in der 2.5.1 und kann das nochmal detailliert beschreiben damit ich weiß was ich nachbauen kann um das zu testen?

Cheers

Bob.Dig

@jegr Die beta hat doch gar kein fix dafür? Zumindest nicht lt. changelog von gestern.

slu

Zitat aus dem Ticket:

2.6.0 snapshots are currently working correctly, and the fix was checked into RELENG_2_5_0. Whatever release happens next will behave correctly either way (e.g. a 2.6.0 release or a 2.5.x point or patch release).

Es müsste also drin sein.

@JeGr

WAN1 ---
         |--- pfSense --- Server1
WAN2 ---

Die pfSense macht ein port forwarding auf Server1, WAN1 ist der default Gateway.
WAN1 funktioniert, bei den Paketen von WAN2 werden die Antworten wieder über den default Gateway (WAN1) verschickt.

Es spielt keine Rolle ob der default Gateway fest auf dem WAN1 sitzt oder es eine Gateway Gruppe ist bei dem er "zufällig" auf WAN1 steht.

JeGr

@slu OK also das klassische Forwarding auf nachgelagertes Gerät. Simpel das zu testen, sollte schnell machbar bzw. testbar sein.

JeGr

@jegr Wenns nochwas gibt, was ihr in 2.5.0/2.5.1 habt und was ich mit SG-Hardware oder normaler Hardware testen soll, ich hab hier ne SG-2100 und ne C2558 Atom Hardware mit der ich komplett random testen kann.

JeGr

@slu Also Aufbau ist soweit fertig.

WAN1 ---  192.168.178.x:23400

         |--- pfSense ...234 | .254  <--->  Server1 172.27.5.55:80

WAN2 ---  192.168.177.x:23400

Logs zeigen auch, dass der Port von den vorgeschalteten Fritzen ankommt.

JeGr

@slu said in 2.5.2-Beta: Test für MultiWAN Problem:

Es spielt keine Rolle ob der default Gateway fest auf dem WAN1 sitzt oder es eine Gateway Gruppe ist bei dem er "zufällig" auf WAN1 steht.

OK wenn das der Testcase war, der funktioniert:

[root@andromeda:~] # curl 46.142.79.84:23400
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>
[root@andromeda:~] #
[root@andromeda:~] #
[root@andromeda:~] # curl 85.216.78.30:23400
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
    body {
        width: 35em;
        margin: 0 auto;
        font-family: Tahoma, Verdana, Arial, sans-serif;
    }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

Container dahinter ist eine Mini-Ubuntu-VM mit NGINX quick installed also nur Testseite verfügbar.

slu

@jegr
sehr cool, vielen Dank fürs testen!

JeGr

@slu said in 2.5.2-Beta: Test für MultiWAN Problem:

@jegr
sehr cool, vielen Dank fürs testen!

wie gesagt wenn nochwas ist, ruhig raus, ich hab die Boxen ja zum Spielen da. Oder auf die Liste für Freitag, dann test ichs live im Talk.

JeGr

@jegr Kurzes Addon dazu:

Weil es ja hieß dass fälschlich das Default GW für die Rückroute genommen wird, habe ich das ganze auf Romy nochmals ge-tcpdump-ed und mir angeschaut, wo Pakete hin und zurück gehen. Sieht für mich soweit legit aus, dass in beiden Dumps die Port 23400/80er Requests raus und rein von der gleichen IP kommen, genauso wie beim anderen WAN1/2. Also kompletter Handshake etc. geht alles über die Interface IP wo es hin sollte.

JeGr

Ein Problem scheint neu aufgepoppt zu sein (wahrscheinlich aber irgendwas UI mäßiges was einfach nur buggy ist): Beim Firewall OUTBOUND NAT Reiter, gibt es aktuell das Problem, dass Regel

a) nicht mehr dupliziert werden können (Maske ist leer wie bei Neueingabe)
b) das Umschalten von automatisch auf manuell erzeugt nicht die aktuellen Auto-Regeln

Das ist aber gerade als Redmine Issue aufgenommen worden.

Edit: Tatsächlich sinds zwei:

https://redmine.pfsense.org/issues/11981
https://redmine.pfsense.org/issues/11982

NOCling

@jegr
Die hast aber sehr zielsicher erschnüffelt, alle Achtung!

JeGr

@nocling Das waren nicht beides meine, ich habe nur gesehen, dass bei 2.6 und 2.5.2 der gleiche Post aufpoppte mit "NAT Rule Duplication Error" und die Masken leer bleiben. Also zwei Dev Systeme angeworfen und geprüft - trat auf (aber bei Outbound NAT nicht bei Redirections inbound wie zuerst gedacht). Als ich dann die eine Maschine auf automatic NAT zurücksetzen wollte hab ich noch Manual ausprobiert -> keine Regeln wurden erstellt. War eher Zufall ;)

slu

@jegr said in 2.5.2-Beta: Test für MultiWAN Problem:

wie gesagt wenn nochwas ist, ruhig raus, ich hab die Boxen ja zum Spielen da. Oder auf die Liste für Freitag, dann test ichs live im Talk.

mir ist noch was eingefallen was ich seither noch nicht genauer untersuchen konnte.
In der 2.5.1 wollte ich den Namen eines Interfaces ändern, da kam dann eine Fehlermeldung und das Speichern war nicht möglich.

Ich hatte dann im Forum gesucht und das war/ist irgend ein Problem mit ipv6 (war und ist auf dem Interface aber nicht aktiv).

Sorry ich bekomme das nicht mehr genau zusammen, daher die Frage kannst Du das mal testen?
Das Interface war kein VLAN, ganz normale Ethernet Schnittstelle.

fireodo

@slu said in 2.5.2-Beta: Test für MultiWAN Problem:

Ich hatte dann im Forum gesucht und das war/ist irgend ein Problem mit ipv6 (war und ist auf dem Interface aber nicht aktiv).

Temporär der Schnittstelle eine beliebige IPv6 Adresse verpassen, dann in DHCPv6 RADVD deaktivieren und anschliessend die temporäre IPv6 entfernen - voilà!

Schönen Tag noch,
fireodo

slu

@fireodo said in 2.5.2-Beta: Test für MultiWAN Problem:

Temporär der Schnittstelle eine beliebige IPv6 Adresse verpassen, dann in DHCPv6 RADVD deaktivieren und anschliessend die temporäre IPv6 entfernen - voilà!

Ja genau das war das Problem, vielleicht ist das in 2.5.2 auch behoben.

JeGr

@slu Ist eigentlich nach meinem Verständnis nicht per se ein Bug. Wenn die Kiste auf DHCP/DHCP6 default eingestellt ist, und auf dem LAN logischerweise dann auf static IP/Track IF dann für IPv6 fähige Geräte bereitstellt, dann muss auch DHCP6 laufen für DNS Unterstützung etc.

Das man die IF Beschreibung dann nicht ändern kann - OK - das wäre Bugmaterial. Aber dass ich nicht einfach v6 abschalten kann ohne vorher DHCP6 Server abzuklemmen - das macht Sinn. :)

Aber können wir am Freitag mal durchspielen.

slu

@jegr said in 2.5.2-Beta: Test für MultiWAN Problem:

@slu Ist eigentlich nach meinem Verständnis nicht per se ein Bug. Wenn die Kiste auf DHCP/DHCP6 default eingestellt ist, und auf dem LAN logischerweise dann auf static IP/Track IF dann für IPv6 fähige Geräte bereitstellt, dann muss auch DHCP6 laufen für DNS Unterstützung etc.

Ich würde dir zustimmen, aber auf der System war nie ipv6 aktiviert und ist es auch nicht.
Evtl. kommt das aber darauf an wann die pfSense installiert wurde und wie damals der Default war...