Messages

HA Proxy Setup for Omada

### Omada Conditions ###

Code Select Expand


oc_condition_1
Condition type = Host matches
Host String = omada.domain.tld (your public domain)

oc_condition_2
Condition type = Host regex
Host Regex = ^omada\.domain\.ltd(:([0-9]){1,5})?$


### Omada Rules ###

Code Select Expand


oc_rule_1   
Test type = IF[default]
Select conditions = oc_condition_1
Execute function = Use specified Backend Pool
Use Backend pool = omada_pool

oc_rule_2
Test type = IF[default]
Select conditions = oc_condition_1,oc_condition_2
Execute function = http-request header set
HTTP Header = host
Header Content = omada.domain.tld:8043

oc_rule_3
Select conditions = Nothing selected
Execute function = Custom Rule
Option pass-through = http-response replace-value location 8043 %[hdr(location),regsub(8043,443)]


### Omada Server ###

Code Select Expand


omada_server
Type = static
FQDN or IP = 192.168.1.0 (your localhost ip)
Port = 8043
Mode = active
SSL = true
Verify SSL Certificate = false

### Omada Pool ###

Code Select Expand


omada_pool
Servers = omada_server
Select Rules = oc_rule_2,oc_rule_3


### Public Service ###

Code Select Expand


public_https
Select Rules = oc_rule_1


Hallo,

Floating Regeln greifen vor den Interface Regel

https://docs.opnsense.org/manual/firewall.html#processing-order

manuelle Floating Regel 'Zulassen von WAN nach Interfaces' ?
 

Wenn ich den Live-View der Firewall betrachte habe ich immer folgende Meldungen:
BUERO Dec 8 22:03:13 192.168.1.30   192.168.2.30 icmp let out anything from firewall host itself

Die Regel ist eine Floating Regel aber ich verstehe nicht warum diese zu tragen kommt an dieser Stelle.

Für deine manuelle Floating Regel ist auch kein logging aktiviert deshalb taucht 'Zulassen von WAN nach Interface' im Live-View auch nicht auf die wird vermutlich aber dein Problem sein, 'let out anything from firewall host itself ' ausgehende Pakete treffen halt zu.

Aufruf von https://79.13.13.13 von Stelle A funktioniert, von Stelle B kommt ein Timeout (Dual-Gateway habe ich oben in der Darstellung einfach weggelassen, da unerheblich).

* ok, bei dem oben erwähnten Verhalten sollte das von Stelle A auch nicht funktionieren
  von Stelle B doppeltes NAT der Telekom Router sieht halt ausgehende Verbindung von
  10.28.100.100 die er dann aber auf die gleiche IP eingehend weiterleiten soll

1) DNS-Auflösung des DYNDNS-Hostnamens intern nicht auf öffentliche IP des Telekomrouters auflösen lassen sondern auf WAN-IP der OPNsense

dyndns auf die WAN IP bzw. wenn die Portweiterleitungen nicht auf unterschiedliche Hosts gehen besser gleich auf die IP vom Host

2) Bei den NAT Regeln bei Interface sowohl WAN-Interface (so war es standardmäßig) als auch LAN-Interface hinzugefügt.

Automatic outbound NAT rule generation sollte reichen

Nun scheint es zu funktionieren - ob das aber eine saubere Konfiguration ist, weiß ich nicht. Die Doku gibt hierzu auch nicht viel her.

Optimal ist doppeltes NAT nicht besser wäre ein vernünftiges Routing oder WAN-Anbindung über Modem .. wenn das mit dem Telekom Router machbar ist

official HAProxy Documentation
http://cbonte.github.io/haproxy-dconv/2.2/configuration.html
HAProxy Enterprise Documentation
https://www.haproxy.com/documentation/hapee/

Dokumentation der Enterprise ist etwas ausführlicher bzw. besser Dargestellt
allerdings zu beachten da sind Features dabei die der Enterprise vorbehalten sind.

Muss man sich halt Gedanken machen wo das in der GUI einzutragen ist.

*Geht zwar auch über die haproxy.conf eine HAProxy Konfiguration vorbei an der OPNsense GUI
macht aber nicht wirklich Sinn, dann ist besser HAProxy auf einem externem System laufen zu haben.

Bei einigen Provider-Routern werden anfragen vom LAN auf die eigene Public IP blockiert
bzw. auf die intern umgeleitet z.B. kommt das bei einigen Digiboxen der Telekom vor

* das dann am besten über internen DNS lösen

Wie ist die WAN Anbindung der OPNsense realisiert ?

Hallo,

* any = alle IP Adressen
LAN net = das Netzwerk auf dem LAN interface
wenn LAN net als Source angegeben wird muss das auch explizit die Quelle sein

Beispiel:

auf dem LAN interface 192.168.10.1/24
Rechner 1 hat IP 192.168.10.54/24 (dhcp vom LAN)
Rechner 2 hat IP 192.168.50.44/24 (Statische IP)
bei (* any) trifft das auf Rechner 1 und Rechner 2 zu
bei (LAN net) nur auf Rechner 1

Hi,
zum zum Thema Broadcom Karten hab ich :

Broadcom NIC verwirft Pakete (bce,bge) in Zeile 2 anpassen

/boot/loader.conf.local ( nicht vorhanden )

kern.ipc.nmbclusters="1000000"
hw.bge.tso_enable=0
hw.pci.enable_msix=0

wenn es nicht hilft mal nach /boot/loader.conf.local im Zusammenhang mit Broadcom  Forum suchen

1. bitte vom VPN Client aus Verbindung herstellen und tracert 192.178.9.146 ums mal einzugrenzen

2. Regel 1 - sollte auf OpenVPN (Tunnel Rule) nicht aufs LAN

Wenn das Ganze jetzt noch restriktiv sein soll

mal ohne die Ports 5004 und 7070-7109 versuchen (5060 reicht meist aus)

bei Outbound Destination das "VOIP Netzwerk" der DG rein

und Port Forward und Firewall Source ebenfalls "VOIP Netzwerk der DG"

VOIP Netzwerk der DG falls das irgendwo Dokumentiert ist ,
ist meist ein Netzwerk also ein größerer IP-Adressenbereich

Die Telefonanlage soll von außen erreichbar sein , von wo wird dir Verbindungsaufbau versucht WAN2 oder von einem anderen Standort aus ?
Client von WAN2 aus Problem "doppeltes NAT" , "UDP Timeout" ? 
Sonst RTP Ports Freigabe , RTP Port Weiterleitung ,
Konfiguration der Ports für den VOIP-Client in der TK-Anlage und auf dem Client selbst?

bei VOIP kann das halt an so ziemlich allem liegen

Auf die schnelle,
Firewallregeln für OpenVPN vorhanden mal testweise alles zugelassen,
den OpenVPN Service mal neu gestartet nach dem eintragen der Netze ?
'auf der Client conf must du eigentlich nichts eintragen solle mit IPv4 Local Network erledigt sein'

Werde leider aus dem oberen Plan nicht schlau wie die Anbindung ans Öffentliche Netz realisiert ist,
das Synology war ja nur als VPN-Server im Lan.

ist die OPNsense neu dazugekommen ?     

Outbound NAT (VOIP_Server = IP TK-Anlage bzw. Fritzbox )

Source address: ist der Alias die IP der Fritzbox ?
Destination address : any

reicht Port 5060 laut Deutsche Glasfaser nicht das noch andere Ports für die SIP-Signalisierung gebraut werden

Vermute auch das in den VPN Einstellungen das Remotenetz fehlt,
im OpenVPN bei IPv4 Local Network (push route openvpn) deine Netze auch eingetragen auch das Remote

Die Frage ist die OPNsense nur als VPN-Server im Lan oder hat sie auch einen eigenen WAN Anschluss ?

Wenn OPNsense nur als VPN-Server im Lan hängt und es mit dem Synology NAS funktioniert hat die IP Netze gleich sind sollte es nicht am Routing des Site2Site VPN Gateway liegen.

Ändere mal beim Forward This Firewall auf WAN address
die LAN Rules sollten eigentlich unnötig sein wenn ausgehende Verbindungen fürs LAN zulässig sind

wenn dann nicht geht zum !testen!:

Firewall -> NAT -> Outbound -> Hybrid outbound NAT rule generation

Interface: WAN
Protokoll ANY
Source address: VOIP_Server
Source Port: any
Destination Port: any
target: Interface Address
Static Port: harken