Messages

1

German - Deutsch / Re: OPNsense: DNS - Adressen vom ISP (PPPoE / WAN)?

« on: June 18, 2023, 09:15:51 pm »

Hallo Florian,

Ich habe dazu als Dienst "Dnsmasq-DNS" aktiviert, diesem den unbenutzten UDP-Port 52 zugewiesen, und dann den Dnsmasq-Dienst quasi zugenagelt und nur noch für localhost erreichbar gemacht. Im Unbound konnte ich dann eine Ausnahmeregel unter "Query Forwarding" einrichten, welche alle Anfragen betreffs der Domains "tel.t-online.de" und "sip-trunk.telekom.de" an 127.0.0.1:52 deligiert.

Klingt gut - die Resolver werden dann durch Dnsmasq-DNS in die resolv.conf übernommen und in Unbound stehen die DNS-Server für alle anderen Systeme - richtig?

Viele Grüße, Uwe

2

German - Deutsch / Re: RTP-Pakete von Telekom blockiert?

« on: June 18, 2023, 08:29:11 pm »

Hallo,

vielen Dank für die Hilfe!

Mittlerweile läuft es.
Angehängt sind Bilder mit Aliasen / Outbound-NAT-Regeln mit denen es funktioniert.

Es ist reproduzierbar - sobald in der Outbound NAT-Regel zu RTP die Fritz!Box
als Source eingetragen wird, funktioniert es nicht mehr.

Mit "Any" als Source funktioniert alles.
Der Alias auf die IP-Adresse der Fritz!Box war bzw. ist richtig.

Keine Ahnung, warum es jetzt nur noch so geht.

@Strunzdesign:

Der Grund lag an nicht konfigurierter Medienverschlüsselung (SRTP) im Asterisk

Vielen Dank für den Hinweis!
Die hatte ich beim Debuggen rausgenommen - ist jetzt wieder drin.

An Deiner Fritzbox (dem "SIP-Useragent") musst Du diese Portrange für RTP/RTCP eintragen.

An der Fritz!Box kann man das leider nicht so einfach einstellen.
Im Export der Konfiguration sieht man, dass folgende Ports verwendet werden:
voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060", "tcp 0.0.0.0:5060 0.0.0.0:5060", "udp 0.0.0.0:7078+20 0.0.0.0:7078";
voip_ip6_forwardrules = "udp 5060 # SIP", "tcp 5060 # SIP", "udp 7078-7097 # RTP";
tr069_forwardrules = "tcp 0.0.0.0:8089 0.0.0.0:8089";
tr069_ip6_forwardrules = "tcp 8089";

und die Weiterleitungsregel (falls eingehenden UDP-Pakete schneller sind).

Die hab´ ich bisher nicht angelegt - momentan gibt es keine Probleme.

Grüße, Uwe

3

German - Deutsch / RTP-Pakete von Telekom blockiert?

« on: June 09, 2023, 04:36:33 pm »

Hallo,

seit dem letzten Update (auf Version OPNsense 23.1.9-amd64) funktioniert die Telefonie via Telekom nicht mehr.

Alle RTP-Pakete werden ausgefiltert (obwohl es NAT-Regeln dazu gibt).
Die Telefonie geht über eine Frtiz!Box.
STUN ist aktiviert. Die Signalisierung geht in beide Richtungen.
RTP geht (seit Neuestem) weder rein noch raus.

An den Regeln wurde nichts geändert.

Für die Telefonie ist kein SIP-Proxy (siproxd) eingerichtet - sondern nur zwei NAT-Regeln
(eine für SIP 5060 und eine Outbound für statisches Port-Mapping) eingerichtet.
So hat es immer funktioniert. Versuchsweise habe ich weitere NAT-Regeln für RTP, etc. angelegt.

Auf der Fritz!Box werden die DNS-Server der Telekom verwendet.
Die Telefonie-Einstellungen sind angehängt.

Was mach ich falsch?

Viele Grüße, Uwe

4

German - Deutsch / Interfaces: Diagnostics: Packet Capture: Pakete fehlen?

« on: June 09, 2023, 03:03:29 pm »

Hallo,

wg. Problemen mit der Telefonie habe ich alle Pakete,
mit den Einstellungen im angehängten Bild, mitschneiden lassen.

Rufe ich mit dem Handy (via GSM) an, dann klingelt es - aber man hört auf beiden Seiten nichts.
Klar - das liegt irgendwie an den RTP-Paketen.

Was ich vermisse sind aber schon die SIP-Pakete im Mitschnitt.
Ohne SIP dürfte es IMHO auch nicht klingen - aber da sind keine.

Liegt es vielleicht an einer NAT-Regel für SIP?
Landen Pakete, die über NAT-Regel gehen, nicht im Mitschnitt?

Viele Grüße, Uwe

5

German - Deutsch / OPNsense: DNS - Adressen vom ISP (PPPoE / WAN)?

« on: June 09, 2023, 02:54:51 pm »

Hallo,

kann man die DNS-Adressen, die vom ISP zugewiesen wurden, irgendwo einsehen?
Hier findet man sie nicht:

System => Gateways => Single
System => Settings => General
Interfaces => Overview => WAN interface (wan, pppoe0)
Interfaces => Point-to-Point => Log File

Warum?

Seit dem letzten Update (auf OPNsense 23.1.9-amd64) hab´ ich massive Probleme mit der Telefonie.
Die Telefonanlage ist eine Fritz!Box (7590), die im LAN hängt.
ISP / Telefonie - Anbieter ist die Telekom (Business-Tarif wg. statischer IPv4).

Es gibt eine weitere Fritz!Box (7590), die sich um die Telefonie via SipGate (SIP-Port 5160 statt 5060) kümmert.
Die Telefonie via SipGate funktioniert einwandfrei.

Via Telekom geht wieder mal gar nichts.
(Outbound NAT für statisches Port-Mapping und Port-Forward von 217.0.0.0/13:5060 auf TK-Anlage sind angelegt).

Die Telekom verwendet diverse (Sicherheits-)Mechanismen, die auf DNS basieren.
Deshalb muss man zwingend die DNS-Server der Telekom in der TK-Anlage verwenden.

Hier gibt es zwar eine Liste von DNS-Servern, davon antwortet aber innerhalb von Sek. nur ein einziger:
https://de.ccm.net/faq/1431-dns-server-deutscher-internetanbieter#dns-deutsche-telekom-ag

Ich würde jetzt gerne wissen, welche DNS-Server während der Einwahl mitgeteilt worden sind.

OPNsense ist so konfiguriert, dass bestimmte DNS-Server (also nicht die der Telekom) verwendet werden
([ ] Allow DNS server list to be overridden by DHCP/PPP on WAN). Das soll auch so bleiben.

Grüße, Uwe

6

General Discussion / Re: IPv4: wrong destination for linux client on other side of transparent bridge

« on: May 20, 2022, 09:45:18 pm »

Meanwhile I figured out how to create a cron-entry to flush the arp-cache periodically:

SSH => 8:Shell

Code: [Select]

cd /usr/local/opnsense/service/conf/actions.d
vi actions_arp.conf


Code: [Select]

[clear]
command:/usr/sbin/arp -d -a
parameters:
type:script
message:clearing arp cache
description:Clear ARP Cache


Code: [Select]

service configd restart
configctl arp clear
exit

System => Settings => Cron => + => Clear ARP Cache

But it´s sad that no one seems to know the root cause for wrong entries appearing in arp-cache, randomly (between 5 and 30 days).

7

General Discussion / Re: IPv4: wrong destination for linux client on other side of transparent bridge

« on: April 05, 2022, 06:58:50 pm »

Upgraded to OPNsense 22.1.4 - but it still happend again, today (about 3 weeks later).
Meanwhile I don´t think that it has something to do with DHCP because the lease-timeout
is set to the default-value of 7200 seconds (2 hours)

I solved it again by (temporarily) flushing the ARP-Cache of OPNSense.

Am I the only one with this issue? What the heck is the root-cause?
Is it possible to configure a cron-job to flush the ARP-Table automatically after two weeks?

8

General Discussion / Re: IPv4: wrong destination for linux client on other side of transparent bridge

« on: March 12, 2022, 06:16:45 pm »

In this case the access point is not configured as a transparent bridge

With a Sophos UTM I never every had this issue.
The configuration of the Access-Point has not been modified.
Both Access-Points of the bridge are TP-Link CPE510.
Those Access-Points have no configuration options for "transparency".
The bridge behaves transparent as long as OPNSense sends the pakets back to the origin MAC-Address.

Every now an then, OPNSense uses the wrong MAC-address.
My assumption is that the MAC-address gets replaced during renew of the DHCP lease.

How do I get OPNSense to always recognize the MAC-Address of the outermost header
(the "Bridge-entrance") instead of the MAC-Address of the device behind the bridge?

The OPNSense-tunables are currently set like this - all others have the default-value:
net.inet.icmp.drop_redirect = 1
net.inet.ip.redirect = 1

(Decsribed in here: https://www.freebsdhandbook.com/security/)

9

General Discussion / Re: IPv4: wrong destination for linux client on other side of transparent bridge

« on: April 13, 2021, 10:14:04 pm »

Root cause found: in the static (DHCPv4) IP reservations, the real MAC-Address
of the Client was entered instead of the MAC-Address of the Access-Point.

Ping works right after deletion of static entry and flush of ARP-Table.

10

German - Deutsch / Re: Probleme mit Richtfunk-Verbindung im LAN

« on: April 13, 2021, 09:48:49 pm »

Wie sind die Gateways an den Clients nach dem DHCP durch OPNsense.
Ist da evtl. etwas auf ip vom DHCP Gateway aber fest eingetragen.

Noch ein Update dazu: nein - in den Reservierungen sind keine Gateways eingetragen (siehe "DHCP_127.png").

Als Workaround trag ich jetzt bei allen statischen Einträge zu Clients auf der anderen Seite
die MAC vom Access-Point ein... ist zwar nicht wirklich schön, funktioniert aber zumindest.

11

German - Deutsch / Re: Probleme mit Richtfunk-Verbindung im LAN

« on: April 13, 2021, 09:32:48 pm »

gibt es IP 192.168.x.79 doppelt?
Sprich hat der Raspberr_52:ed:3c auch diese IP-Adresse, genauso wie der Tp-LinkT_49:33:52 unter Linux?

Nein - die IP gibt es nicht doppelt. Die meisten Clients haben einen statischen Eintrag im DHCPv4.
Das passiert auch, wenn ich vom Switch aus einen Ping absetze.
Der Switch hat das "don´t Fragment"-Bit aber nicht gesetzt.

Zumindest wenn die OPNsense als Router das DHCP übernimmt?

Vielen Dank für den Tipp! 

Bis auf den Windows-Client haben alle einen statischen Eintrag im DHCP.
Der Windows-Client bekommt eine Lease.

Die Einträge hatte ich vorab aus einer Liste aller Clients (samt Beschreibung) importiert.
In der Liste standen die echten MAC-Adressen der Clients und nicht die vom AP.

Nachdem ich den statischen Eintrag gelöscht und die ARP-Table geflusht hatte, kam der Ping
sofort an (in der ARP-Table ist jetzt der Eintrag vom Gateway - siehe "ARP_Table_79.png").

Kann man irgendwo festlegen, dass die MAC-Adresse aus dem Request genommen werden soll?
Oder kann man vielleicht irgendwo festlegen, dass die ARP-Tabelle nicht mit den statischen
Einträgen initialisiert wird?

Das würde Fehler vermeiden, wenn ein Client samt statischen Eintrag bei mir lokal
(Erst-)eingerichtet und im Anschluss hinter die AP-Bridge umgezogen wird...

12

German - Deutsch / Re: Probleme mit Richtfunk-Verbindung im LAN

« on: April 13, 2021, 01:09:00 pm »

Es ist wirklich so einfach - ein LAN, zwei APs, zwei Switche, zwei Clients. Kein VLAN, kein QoS, keine sonstigen Filter.

Firewall-Regeln sind egal, weil die Pakete ja beantwortet werden - also nicht ausgefiltert werden.
Sie werden von der OPNsense eben nur an das falsche Ziel geschickt.

Tausche ich die OPNsense ohne jegliche Änderung gegen Sophos UTM (oder Bintec) aus, dann funktioniert alles wieder.

Mit austauschen meine ich konkret: LAN umstecken, WAN umstecken, OPNsense aus, Sophos UTM ein.

Es ist definitiv die OPNsense, die hier Mist baut.

13

German - Deutsch / Re: Probleme mit Richtfunk-Verbindung im LAN

« on: April 12, 2021, 10:06:56 pm »

> Bitte einmal einen richtigen Netzwerkplan der relevanten Teile

Siehe "Netzwerk_LAN.png".

> sowie Screenshots der Regelübersicht von den jeweiligen Schnitstellen

Siehe "Rules_LAN.png".
Es gibt keine selbst erzeugten Floating-Regeln.

Ich hab auch zwei Bilder von den Paketen angehängt (Bilder sagen mehr als Worte  )
Request/Reply Windows-Client (keine Flags) => OK ("ICMP_203.png")
Request/Reply Linux-Client (do not fragment) => Fehler ("ICMP_79.png")

14

General Discussion / IPv4: wrong destination for linux client on other side of transparent bridge

« on: April 11, 2021, 08:33:02 pm »

Hello,

(this is an english copy of https://forum.opnsense.org/index.php?topic=22566.msg107282#msg107282)

following setup with OPNsense 20.7.8 running on an APU4D4:

OPNsense  (LAN)                                                  (LAN)
                 - Switch - Transparent WLan-Bridge - Switch
                 - Client "A"                                        - Client "L" (Linux)
                                                                          - Client "W" (Windows)

Problem: "L" can´t ping "A" BUT "W" can ping "A"  ("A" can ping everything)

What´s important: this setup was perfectly working with Sophos UTM 9 before.

I compared an ICMP-paket and found the following differences:

Request:
  IPv4
    Windows "W": no flags set / Linux "L": don't fragment - bit set
  ICMP
    Windows "W": 32 Byte length (without timestamp) / Linux "L": 48 Bytes (with Timestamp)

Reply:
  IPv4
    Windows "W": no flags set / Linux "L": don't fragment - bit set
    Windows "W": Destination Address = Tp-LinkT_49:33:52 (=> MAC of Access-Point)
    Linux "L": Destination Address = Raspberr_52:ed:3c (=> MAC of Client "L")
  ICMP
    Windows "W": 32 Byte length (without timestamp) / Linux "L": 48 Bytes (with Timestamp)
    Windows "W": response time = 0,088 ms / Linux "L" = 0,154 ms

It seems that OPNsense replaces the MAC-Adress in case "don´t fragment" is set.

What I have tried so far (followed by reboot of OPNsense after each change):
System: Settings: Tunables: net.inet.ip.redirect: 0 => 1
Interfaces => Settings
  ARP Handling: [ ] => [X] Suppress ARP messages
  Hardware TSO: Disable hardware TCP segmentation offload [X] => [ ]
Firewall: Settings: Normalization:  IP Do-Not-Fragment [ ] => [X]
Firewall: Settings: Advanced:
  Network Address Translation: Reflection for port forwards [X] => [ ]
  Network Address Translation: Automatic outbound NAT for Reflection [X] => [ ]
  Disable automatic rules which force local services to use the assigned interface [ ] => [X] 

No Interface has an "upstream gateway" set
Intrusion-Detection ist disabled.

LAN-Interface is configured like this:
  Block private networks: [ ]
  Block bogon networks: [ ]
  MTU: 1500
  MSS: (not set)
  Dynamic gateway policy: [ ] This interface does not require an intermediate system to act as a gateway
  IPv4 Upstream Gateway: Auto-Detect

Is it possible to disabled that "feature" and force OPNsense to always
return the paket to the Source-MAC-Adresse as specified by the initial request?

15

German - Deutsch / Re: Probleme mit Richtfunk-Verbindung im LAN

« on: April 10, 2021, 10:57:31 pm »

> Routet oder bridged ihr über das WLAN?

Es ist kein WLAN-Kärtchen oder USB-Stick in der OPNsense selbst.
Es sind zwei Outdoor Access-Points. Einer arbeitet als Access-Point, der andere als Client.
Ich würde es als transparente Bridge bezeichnen.

Das Setup hat mit der Sophos-UTM (und vorher mit ´ner Bintec-Firewall)
über Jahre hinweg einwandfrei funktioniert.

Hab gerade die Pakete von Windows- und Linux-Systemen verglichen:

Request:
  Frame
    Windows: 74 Bytes (592 bits) / Linux: 98 Bytes (784 bits)
  IPv4
    Windows: kein Flag gesetzt / Linux: Don't fragment gesetzt
  ICMP
    Windows: 32 Bytes Länge (ohne Timestamp) / Linux: 48 Bytes (mit Timestamp)

Reply:
  Frame
    Windows: 74 Bytes (592 bits) / Linux: 98 Bytes (784 bits)
  IPv4
    Windows: kein Flag gesetzt / Linux: Don't fragment gesetzt
    Windows: Destination Address = Tp-LinkT_49:33:52 (=> Access-Point)
    Linux: Destination Address = Raspberr_52:ed:3c (=> anfragender Client)
  ICMP
    Windows: ohne Timestamp (32 Bytes Länge) / Linux: mit Timestamp (48 Bytes Länge)
    Windows: Response time = 0,088 ms / Linux = 0,154 ms

Die OPNsense schickt anscheinend die Pakete nicht mehr an die ursprüngliche
Source MAC-Adresse vom Request, sondern an die MAC-Adresse der
Destination IP-Adresse vom Request, sobald das "Don't fragment"-Flag gesetzt ist.

Hab versuchsweise folgende Option gesetzt und die OPNsense neu gestart:
Firewall: Settings: Normalization:  IP Do-Not-Fragment [X]
Das hat aber nichts geändert - hab´s wieder zurückgesetzt.

Danach hab ich versuchsweise noch folgende Option gesetzt (samt Neustart):
System: Settings: Tunables: net.inet.ip.redirect: 0 => 1
Hat auch nichts gebracht.

Unter Firewall: Settings: Advanced: Network Address Translation waren folgende Optionen noch gesetzt:
  Reflection for port forwards [X]
  Automatic outbound NAT for Reflection [X]
Die hab ich deaktiviert und wieder (nach Neustart) getestet. Hat aber auch nichts geädert.

Bei keinem Interface ist übrigens ein "upstream gateway" festgelegt.

Wie kann man der OPNsense beibringen, dass sie immer die ursprüngliche MAC-Adresse verwendet?