Hi , ich versuche einen Tunnel zwischen zwei OpnSense Servern aufzubauen, leider mit wenig Erfolg.
Die beiden OpnSense-Server laufen aktuell in einer Virtualisierungsumgebung zum Test.
OpenSense1
WAN 192.168.5.236/24
LAN 10.10.0.0/24
OpenSense2
WAN 192.168.5.246/24
LAN 10.20.0.0/24
Grundsätzlich funktioniert der Tunnelaufbau:
Opnsense1
root@OPNsense1:~ # ipsec status
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
Routed Connections:
con1{1}: ROUTED, TUNNEL, reqid 1
con1{1}: 10.10.0.0/24 === 10.20.0.0/24
Security Associations (1 up, 0 connecting):
con1[1]: ESTABLISHED 41 minutes ago, 192.168.5.236[192.168.5.236]...192.168.5.246[192.168.5.246]
con1{6}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c0ff9e58_i c925fab0_o
con1{6}: 10.10.0.0/24 === 10.20.0.0/24
OpnSense2
root@OPNsense2:~ # ipsec status
no files found matching '/usr/local/etc/strongswan.opnsense.d/*.conf'
Routed Connections:
con1{5}: ROUTED, TUNNEL, reqid 1
con1{5}: 10.20.0.0/24 === 10.10.0.0/24
Security Associations (1 up, 0 connecting):
con1[6]: ESTABLISHED 40 minutes ago, 192.168.5.246[192.168.5.246]...192.168.5.236[192.168.5.236]
con1{10}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c925fab0_i c0ff9e58_o
con1{10}: 10.20.0.0/24 === 10.10.0.0/24
in der Firewall ist auf beiden Servern IPSEC für IPv4 komplett geöffnet.
versuche ich von der OpnSense die jeweils andere auf der LAN-IP anzupingen gehen die Pakete über das default-GW auf die Reise und finden leider somit ihr Ziel nicht. Eine entsprechenden Route wurde auf den OpnSense-Servern scheinbar nicht gesetzt
root@OPNsense2:~ # netstat -rn
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.5.144 UGS re0
10.20.0.0/24 link#2 U re1
10.20.0.1 link#2 UHS lo0
127.0.0.1 link#4 UH lo0
192.168.5.0/24 link#1 U re0
192.168.5.136 192.168.5.144 UGHS re0
192.168.5.246 link#1 UHS lo0
Ich bin momentan etwas ratlos, hat jemand einen Tip für mich, wie ich die Pakte in den IPSEC-Tunnel schaufeln kann?
Im Manual https://docs.opnsense.org/manual/how-tos/ipsec-s2s-conn.html steht leider nur zum Schluß
QuoteWith the tunnel active, all that remains is to accept traffic on this tunnel using the Firewall->Rules->IPsec menu option.
ich freue mich über jeden hilfreichen Hinweis.
Grüße Detlev
Auf beiden Test Firewalls muss auf dem WAN Interface der Filter für Private Adressen entfernt werden. Außerdem darf es keinen Gateway auf dem WAN interface geben, am besten alle Gateways deaktivieren. Dann geht auch alles richtig.
Moin, ich habe die Gateway's in meiner Testumgebung deaktiviert, das macht aber leider keinen Unterschied.
Weiterhin gehen keine Daten durch den Tunnel.
Ich betreibe ja zur Zeit nur ein Testsystem, da kann ich auf das Gateway verzichten, aber dem zukünftigen System (hängt über dem WAN-Port direkt am Internet) kann ich nicht das default-GW am WAN-Port entziehen, wie soll es denn dann eine Verbindung ins Internet auf bauen?
Grüße Detlev.
Es ist ein Unterschied ob es eine Testumgebung oder eine Produktivumgebung ist.
Sobald ein Gateway eingetragen ist, wird dem gesamten Traffic von der Firewall eine "Reply-To" Regel gegeben. Damit zwingt die Firewall allen Traffic zur IP des default Gateways, und nicht zurück zum Initiator. Entweder man deaktiviert alle Gateways, oder man setzt "Firewall: Settings: Advanced" "Disable reply-to". In einer Produktivumgebung mit echtem WAN muss man das nicht machen.
Das zweite sind die Filter für Private IP Adressen. Auf dem Interface "WAN" gibt es die Haken "Block private networks", der muss da raus wenn man interne IPv4 Adressen verwendet.
Den Filter bogon- / private- Networks kenne ich, der Haken für private-networks war raus.
Das heißt also, wenn am WAN-Interface priv. Netzwerkadressen erkannt werden, zieht die Firewall automatisch Regeln hoch?
Was mich schon wundert: sobald ich in meinem Szenario ein weiteres Interface konfiguriere, kann ich über das WAN-Interface nicht mehr via https und ssh auf die OpenSense zugreifen. Ich habe aber nirgends eine Konfigurationsmöglichkeit dazu gesehen. Die Sperre kommt aber definitiv von der Firewall, ein pfctl -d auf der Konsole lässt den Zugriff wieder zu, bis zur nächsten Konfigurationsänderung.
wie verhalten sich denn die "Automatically generated rules" ? Die Firewall-Rules werden doch von oben nach unten, bis zum ersten Match abgearbeitet, an erster Stelle steht bei den "Automatically generated rules" ein IPV4 DENY ALL.
Ist hier die Reihenfolge anders?
Was mich
Nein, sobald ein Gateway auf einem Interface explizit konfiguriert wird, wird ein Interface zu einem WAN interface mit reply-to Regeln.
Der Paket flow ist ungefähr so:
https://forum.opnsense.org/index.php?topic=36326.0
Es gibt außerdem noch eine Aufteilung zwischen Interface, Interface Gruppen und Floating Regeln in der Reihenfolge:
https://docs.opnsense.org/manual/firewall.html#processing-order
Ich habe schon mehrfach lokale Testszenarien mit IPsec aufgebaut und kenne die ganzen Fallstricke. Es ist halt nicht das gleiche wie ein Testscenario über WAN.
Zur GUI, ich ändere den Port immer auf 4443 über
System: Settings: Administration: TCP Port
und setze mir Filter Regeln auf die Interfaces von denen ich auf die Firewall zugreifen muss. (Destination: This Firewall, Destination Port 4443). Danach ist nie wieder irgendwas komisches passiert oder GUI unerreichbar.
Hi,
wenn auch spät, trotzdem Danke für Deine Unterstützung.
Grüße Detlev.