Messages

1

24.1 Legacy Series / Multi-WAN: Fallback is used without trigger.

« on: May 07, 2024, 04:16:15 pm »

Hey there,

so i've configured a multi-wan setup here. For a bit more context, my ISP disconnects and renews my ip every 24h. I have a machine that needs to be always online and I want only this machine to always establish a connection.

So, what I want is this: When wan_1und1 is up, everything should go through this and the port forwarding rules should apply. If wan_1und1 is down, fallback to wan_lte and only one machine (192.168.178.92) should be able to connect to one specific host.

My Problem is, that the fallback connection is always used. I dont like this, because this is a metered network (Cellular LTE).

I am pretty sure, that this is because of port forwarding. Apparently port forwarding has some higher priority in the firewall rules.

When looking at the Reporting -> Insight on Interface wan_lte i can see that there is traffic on the port forwarded ports (i.e. 30303).

Code: [Select]

                WAN_1UND1         WAN_LTE_FALLBACK
                 :                        :
                 : LTE                    : DSL
                 :                        :
             .---+---.              .-----+-----.
             | IK41  |     Modems   | Vigor167  |
             '---+---'              '-----+-----'
192.168.51.1/24  |                        |
        Ethernet |                        | PPPoE
                 |                        |
            .----+----.             .-----+-----.
            | wan_lte |    Gateways | wan_1und1 |
            '----+----'             '-----+-----'
192.168.51.11/24 |                        | "default"
                 |      .----------.      |
                 +------| OPNsense |------+


See the screenshots for more info.

What ive tried (without success):
- I've removed the automatically created port forward wan_1und1 rules with custom ones, to be able to set a gateway. This should only be possible via wan_1und1 now, but it isnt. it is also passed through wan_lte.
- I've added a wan_LTE rule to completely block incoming traffic (it doesnt).
- I've disabled sticky connections for Multi-WAN.

Is this a bug? I would be happy if you have some ideas for me!

Best
inDane

2

German - Deutsch / Re: Yet another VoIP Thread.

« on: January 19, 2024, 05:24:36 pm »

OK, klarer Anwender Fehler... ?

Ich hatte Floating Rules drin die sagten:
Von VoIP_1und1 zu LAN erlauben v4 + v6
Von LAN zu VoIP_1und1 erlauben v4 + v6

VoIP_1und1 ist ein Alias mit allen RTP SIP Stun-Servern von 1und1.

Diese Floating rules hatte ich bei der pfSense ebenfalls drin und ich meine auch, dass die notwendig waren... anyways... ich habe die entfernt und siehe da.. VoIP via GO-Box/ipv4 Funktioniert. Das ist mir peinlich.

Ich könnte mir vorstellen, dass die Floating Rules die NAT rules übertrumpft haben und deswegen die NAT Outbound rules kaputt gegangen sind...

Die Rules die ich in der pfSense hatte, habe ich mal als Attachment angehängt. OPNsense scheint das nicht zu mögen... Ich mache aber gleich noch den Gegentest und versuche VoIP mit der Regel wieder kaputt zu machen.

EDIT: Jop, das ist der Fehler. Baue ich die Floating rules wieder ein, klappt VoIP (IPv4) nicht mehr. Ist das as expected oder ist das ein Bug?

Beste Grüße
inDane

3

German - Deutsch / Re: Yet another VoIP Thread.

« on: January 18, 2024, 05:27:33 pm »

Hi Robert,

Welcher STUN-Server ist denn in der GO-Box eingestellt? Bei 1und1 sollte es wohl stun.1und1.de sein?

Korrekt.

Folgende Beobachtungen im WAN.pcapng:
- Mit STUN, Anruf zu 0311: RTP hin und zurück zwischen WAN_IP und 1und1 in Ordnung, ich höre etwas.
- Ohne STUN, Anruf zu 0311: source ip ist die local ip der GO-Box... Ich höre nichts.
- Mit STUN, Anruf zu meiner Handynummer: RTP lediglich von meiner WAN_IP zu 1und1. Ich höre nichts.
- Ohne STUN, Anruf zu meiner Handynummer: RTP lediglich von meiner WAN_IP zu 1und1. Ich höre nichts.

Das bezieht sich alles auf die GO-Box ipv4 +NAT.
Linphone via IPv6 funktioniert einwandfrei ohne STUN.

Aufgrund von 192.168.178.xxx vermute ich eine FRITZ!Box? Was hast du denn da für ein Modem?

Jain, ich hatte eine FB und aufgrund von statischer IP vergabe das Netz so beibehalten. Eine FB befindet sich derzeit bei mir nicht im LAN. Die Komponenten sind Draytek Vigor 167, OPNsense, GO-Box 100.

Beste Grüße
inDane

4

German - Deutsch / Re: Yet another VoIP Thread.

« on: January 18, 2024, 10:33:13 am »

Hi Robert,

habe ich gemacht. Stun ist aus und die Einstellung in der Go-Box "Zufällige Ports benutzen" ist gesetzt 5060-5076 (das sind die default werte).

Ich habe das Modem als auch die opnsense neugestartet. Ohne Erfolg.
Was mich wirklich skeptisch macht, ist, dass am OPNsense WAN interface überhaupt keine ipv4 RTP-Pakete zurück kommen. Also ausgehend sendet er die ganze Zeit, wenn ich einen Anruf gestartet habe, aber es kommt gar nichts zurück. Die SIP Aushandlung funktioniert einwandfrei und bei RTP ist dann einfach Ende.
Selbst wenn NAT an dieser Stelle kaputt wäre, müsste doch irgendwas am WAN interface ankommen oder? In dem Paket was raus geht, steht ja meine public ipv4 als source drin...

EDIT: Das steht im SIP Header... Versucht die Gegenstelle möglicherweise an 192.168.178.7 zurück zu schicken?

Via: SIP/2.0/UDP 192.168.178.7:5069;received=<meineWAN_IP>;branch=<xyz>;rport=5069
    Transport: UDP
    Sent-by Address: 192.168.178.7
    Sent-by port: 5069
    Received: <meineWAN_IP>
    Branch: <xyz>
    RPort: 5069

EDIT2:
mhh IETF RFC 3581 schreibt:

   When a server attempts to send a response, it examines the topmost
   Via header field value of that response.  If the "sent-protocol"
   component indicates an unreliable unicast transport protocol, such as
   UDP, and there is no "maddr" parameter, but there is both a
   "received" parameter and an "rport" parameter, the response MUST be
   sent to the IP address listed in the "received" parameter, and the
   port in the "rport" parameter. The response MUST be sent from the
   same address and port that the corresponding request was received on.
   This effectively adds a new processing step between bullets two and
   three in Section 18.2.2 of SIP [1].




Vielen Dank für die Unterstützung.
inDane

5

German - Deutsch / Re: Yet another VoIP Thread.

« on: January 17, 2024, 02:20:40 pm »

Hi Saarbremer,
ich habe sogar noch einen drauf gesetzt und hab die Karre komplett rebootet!

Via ipv4 kommen gar keine zurück, wie es ausschaut. In meinem vorherigen Post ist auf der rechten seite jeweils das WAN interface pcap.


Via ipv6 (vom Laptop mit Linphone) klappt alles wie man es erwarten würde. Via Ipv4 kommt kein RTP zurück.

VG
inDane

6

German - Deutsch / Re: Yet another VoIP Thread.

« on: January 17, 2024, 01:15:00 pm »

Hallo Robert,
danke Dir für deine Ideen!

zu 1.
Ich habe Port Forwards gebaut für die SIP und RTP ports. (s. Attachment)
Auf der GO-Box sind folgende Ports eingetragen. 5060 und 7078:7082. (s. Attachment)

Hat nichts verändert. Ich habe die portforwards jetzt aber vorerst drin gelassen.



zu 2.
Was auffällt ist, dass die RTP Pakete nur nach außen gehen, aber keins rein kommt.
Im wireshark habe ich folgenden filter benutzt"sip || rtp || stun".
Ich habe in den folgenden Bildern meine Telefonnummer und meine public IP entfernt.


https://i.imgur.com/K87niJN.png

https://i.imgur.com/I58L6Wn.png


Die RTP Pakete haben SRC Port 7078 und Dest Port 40286.

Hast Du eine Idee dazu?

VG
inDane

7

German - Deutsch / [Solved] Yet another VoIP Thread.

« on: January 16, 2024, 06:15:13 pm »

Nabend!

Ich bin am Ende meines Lateins angekommen und hoffe, dass irgendwer von euch mir einen Impuls geben kann, warum der shit nicht funktioniert.
Kurzer Kontext: Mein VoIP funktioniert nicht. Das ging aber, als ich meine pfSense, anstelle der OPNsense, als Router hatte. Ich dachte mir aber, ich wechsel zu OPNsense.Die Config habe ich (meines Wissens nach) 1 zu 1 von der pfSense übertragen. WAN klappt alles, Internet ist da. Für VoIP benutze ich primär eine GO-Box 100, das ist eine DECT Station von Gigaset. Die kann sich anmelden, SIP Registrierung geht. Ich kann Anrufe starten und empfangen, aber es kommt ums verrecken kein Ton...

Hier der Aufbau:

      WAN / Internet
            :
            :
            :
      .-----+-----.
      |  Modem  | 
      '-----+-----'
            |
        WAN_1und1 | PPPoE
            |
      .-----+------.   
      |  OPNsense |
      '-----+------'   
            |
        LAN | 192.168.178.1
            |
      .-----+------.
      | LAN-Switch |
      '-----+------'
            |
    ...-----+------ .-----+------.
                        | GO-BOX    | 192.168.178.7
                        '-----+------'


Ich habe Outbound NAT auf static gestellt für die Go-Box. Ich habe hier schon einiges rumprobiert: "manual", "hybrid", das ganze LAN zu WAN static zu NATten etc etc. Es half nichts bisher.

s. Attachment.

Es ist kein Port-Forwarding zu meiner GO-Box aktiv, da dass eigentlich unnötig sein sollte.

Ich hatte auch testweise floating rules drin, die in und out von den 1und1 SIP/RTP Servern erlauben.
Alles ohne Erfolg.


Ich möchte fast sage OPNsense hat hier einen Bug. Oder vielleicht pfSense, weil es dort funktioniert hat?... Keine Ahnung, ich bin am Ende. Ich teste seit drei Tagen. Dieser Post ist quasi die letzte Chance, danach installiere ich wieder pfSense. Auch wenn ich das eigentlich doof finde, weil mir OPNsense sympathischer ist.


Beste Grüße
inDane


Info am Rande: Mit Linphone auf meinem Laptop gingen SIP calls. Allerdings ging das ganze über ipv6 (hab das via Wireshark gesehen). Die GO Box kann kein IPv6.