Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - puseidr

#1
Ich habs :)

Ich hatte die automatische Lockout Regel nachgebaut und hatte da als Destination "This Firewall" stehen, habe jetzt die Regel so angepasst dass alle 3 IPs als Destination drin stehen (über ein Alias) und zack schon gehts! :)
#2
Hallo,
in meinem HA-Cluster ist mir aufgefallen, dass das Webinterface immer nur auf der Master-FW erreichbar ist.

Beispiel:
FW1-LAN-IP 192.168.100.11
FW2-LAN-IP 192.168.100.12
Virtuelle LAN-IP 192.168.100.1 (CARP)

per Ping sind alle 3 IPs erreichbar, wenn ich mit nmap einen Portscan mach ist nur auf den IPs 192.168.100.1 und 192.168.100.11 das Webinterface auf Port 443 erreichbar, auf der 192.168.100.12 is alles dicht.

Wenn ich nun auf der FW1 das CARP deaktiviere wandert die IP 192.168.100.1 auf die FW2, und dann komm ich über die 192.168.100.12  sowie 192.168.100.1 auf das Webinterface die FW2, allerdings komm ich nie zeitgleich auf das Webinterface der FW1 UND FW2.

Hab ich da was falsch konfiguriert oder ist das Verhalten gewollt? Ich würde halt beim Updaten der FW erstmal die Backup-FW patchen anstatt die, die Master der ganzen vIPs ist.
#3
Das Problem besteht leider immer noch und ich konnte es auf Diversen Testumgebungen mit unterschiedlicher Hardware und OS reproduzieren:
- Windows 10 Pro
- Windows Server 2016 Standard
- Windows Server 2019 Standard

Mich wundert es, dass es noch keinem anderen aufgefallen ist. Scheinbar nutzt niemand OpnSense als HyperV-VM.
#4
das hat leider auch nix gebracht
#5
German - Deutsch / TCP Connection Timeout auf Hyper-V VMs
September 06, 2019, 11:22:32 AM
Hallo zusammen, ich habe eine merkwürdigen Verhalten festgestellt und auch auf anderer Hardware reproduzieren können, leider fehlt mir noch die Lösung dazu.


Zum Aufbau:

Ich habe einen Windows Server 2019 Standard mit Hyper-V darauf ist eine VM (Gen2) mit OPNSense 19.7 (2GB RAM, 4 Kerne) und 2 virtuellen NICs (1x am externen Switch für WAN und 1x am internen Switch für das LAN).
Weitere VMs sind ebenfalls Windows Server 2019 und hängen alle am "internen Switch" also LAN.
In der OPNSense habe ich unter Unbound DNS "DNS Query Forwarding" aktiviert damit bei den VMs die Namensauflösung passt und sie ins Internet kommen.

Das Problem:

Das Browsen (Chrome/Firefox/IE) funktioniert auf den VMs eigentlich wunderbar, allerdings kriegen Anwendungen auf den VMs die HTTP/S Requests ins Internet machen ab und zu TCP Connection Timouts (nach ca 30 Sekunden).

Reproduzieren kann man recht gut, indem man mit Chrome Inkognito Tabs öffnet und einfach versucht irgend welche Internet Seiten aufzurufen. In 2-3 von 19 Aufrufen kommt es zu diesen Timeouts.

Sobald man die OPNSense umgeht, indem man die VMs an den "externen Switch" hängt funktionieren alle Requests ohne Timeout. Ich hab das Verhalten hab ich auch bei anderen VMs fesgestellt (CentOS 7 , Debian 10, Windows 10).
Ich hab testweise die OPNSesne auch mal als Generation 1 VM betrieben aber auch da tritt das auf.

Hat jemand eine Idee woran das liegen kann? Auf physischer Hardware lässt sich das Verhalten nicht reproduzieren, ich denke es liegt irgendwie an der Virtualisierung.
#6
Wollte nur mal kurz zur Lösung beitragen..

Das Problem, war auf der Sophos Firewall war NAT-T nicht aktiviert, und die Sopohs war auf ihrem WAN-Interface in einem privaten Netzwerk hinter einer 2. Firewall.
#7
Hallo zusammen,

ich bin gerade dabei eine Site2Site IPSec (v1) Verbindung zwischen einer Sophos UTM 9.6 und OPNsense 19.1 einzurichten.

Nach ein paar anfänglichen Problemen mit NAT kann der Tunnel zwischen den 2 Firewalls aufgebaut werden und in der OPNsense steht als State: INSTALLED Routed, was ja eigentlich bedeutet, dass alles gut ist oder?

Zum testen habe ich erstmal ANY-Regeln in der Firewalls (IPsec) erstellt, allerdings kann ich nix in den LAN Netzen hinter den Firewalls erreichen (von beiden Seiten aus).

Das Firewall Log zeigt leider auch nix an, dass irgendwas geblockt würde (da sieht man einfach gar nix :-( )
Laut der Routing Übersicht gibt es auch eine Route ins Remote-Netzwerk der 2. Firewall.

Habs zu Testzwecken auch schon mit 2 OPNsense firewalls versucht, aber auch da kann ich die entfernten Netzwerke nicht erreichen (Tunnel geht, Traffic aber nicht)


Kennt das Problem jemand? Muss zusätzlich zu dem IPsec Tunnel (inkl. Phase 2) eingerichtet werden damit man mit den Remote-Netzen reden kann?