1531
German - Deutsch / Re: RDS FARM NAT
« on: September 19, 2023, 09:43:16 pm »
Benutzte doch einen RD-Gateway Server. Dann musst du nur auf den das Port Forwarding einstellen.
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.
1532
German - Deutsch / Re: Telekom Telefonie Funktioniert nur in eine Richtung
« on: September 19, 2023, 02:05:38 pm »
Wenn du mehrere öffentliche IP Addressen am Glasfaseranschluss an der Opnsense hast, ist es am einfachsten ein 1:1 NAT auf die Fritzbox einzurichten. Dann gibt es mit Telefonie keine Probleme.
Ansonsten ist es wichtig, bei Outbound NAT "Static Port" zu aktivieren. Hier muss aber der Static Port nur für die UDP (RTP) Port range aktiviert sein. Das heißt es müssen mehrere Outbound NAT Regeln für die Telefonie gemacht werden.
Ansonsten ist es wichtig, bei Outbound NAT "Static Port" zu aktivieren. Hier muss aber der Static Port nur für die UDP (RTP) Port range aktiviert sein. Das heißt es müssen mehrere Outbound NAT Regeln für die Telefonie gemacht werden.
1533
German - Deutsch / Re: Telekom Telefonie Funktioniert nur in eine Richtung
« on: September 19, 2023, 01:31:53 pm »
Wenn eine der beiden Seiten oder beide Seiten nichts hören, dann werden die Sprachpakete nicht übertragen. Die Sprachpakete werden per RTP (Real-Time Transport Protocol) übertragen, das sind meistens upper (1024-65535) UDP Ports.
Im SIP Protokoll ist SDP (Session Description Protocol) eingebaut, welches bei den SIP User Agents (Also allen Geräten die untereinander SIP und RTP machen) Die Medienattribute austauschen. Darin werden die Sockets (IP Adresse+Port) der Endpunkte festgelegt zwischen denen RTP (Also Sprachpakete) ausgetauscht werden. Wenn NAT dazwischen ist, muss STUN verwendet werden, damit die falsche interne IP Adresse im SDP Paket mit der richtigen IP ausgetauscht wird.
Zusammengefasst:
- Entweder blockiert die Firewall die Sprachpakete
- oder es wird NAT verwendet aber es gibt keinen STUN Server und die Sprachpakete werden an den falschen Socket gesendet.
- oder die Firewall ändert die ankommenden und abgehenden Ports, das kann man mit static port verhindern
Im SIP Protokoll ist SDP (Session Description Protocol) eingebaut, welches bei den SIP User Agents (Also allen Geräten die untereinander SIP und RTP machen) Die Medienattribute austauschen. Darin werden die Sockets (IP Adresse+Port) der Endpunkte festgelegt zwischen denen RTP (Also Sprachpakete) ausgetauscht werden. Wenn NAT dazwischen ist, muss STUN verwendet werden, damit die falsche interne IP Adresse im SDP Paket mit der richtigen IP ausgetauscht wird.
Zusammengefasst:
- Entweder blockiert die Firewall die Sprachpakete
- oder es wird NAT verwendet aber es gibt keinen STUN Server und die Sprachpakete werden an den falschen Socket gesendet.
- oder die Firewall ändert die ankommenden und abgehenden Ports, das kann man mit static port verhindern
1534
German - Deutsch / Re: WireGuard Verbindung Android vs iOS
« on: September 18, 2023, 12:22:29 pm »
@anym001
Ich hab gerade ein Tutorial fertig geschrieben für IPsec Einwahl mit den neuen IPsec Connections. Vielleicht hättest du Zeit es auszuprobieren, da du oben geschrieben hast, dass du IPsec ausprobieren willst und jetzt schon länger Probleme mit Wireguard hast.
Wenn du Probleme hast unterstütze ich dich gerne, da ich dadurch das Tutorial verbessern kann.
https://forum.opnsense.org/index.php?topic=35840
Ich hab gerade ein Tutorial fertig geschrieben für IPsec Einwahl mit den neuen IPsec Connections. Vielleicht hättest du Zeit es auszuprobieren, da du oben geschrieben hast, dass du IPsec ausprobieren willst und jetzt schon länger Probleme mit Wireguard hast.
Wenn du Probleme hast unterstütze ich dich gerne, da ich dadurch das Tutorial verbessern kann.
https://forum.opnsense.org/index.php?topic=35840
1535
German - Deutsch / Re: Port Forward funktioniert nicht; nginx DataStream funktioniert
« on: September 17, 2023, 07:30:16 pm »
Hab mich noch an was erinnert was ich mal gelesen habe:
Wenn zwei PPPoE WAN Verbindungen vom selben ISP die selbe Gateway IP Adresse benutzen.
https://github.com/opnsense/core/issues/5238
Edit: Achso im Schaubild steht Kabel und DSL aber 2 mal PPPoE. Wieder verwirrt worden. Sorry
Ich würde einfach 2 Port Forwarding Regeln anlegen, für jedes WAN interface eine eigene, und schauen ob es dann funktioniert. Wenn diese Regeln auch nicht matchen dann gibt es da irgend ein anderes Problem als die Gateway Gruppe. Vor mehreren Jahren hatte ich auch eine Opnsense an DSL und Kabel gleichzeitig mit Gateway Gruppe betrieben, aber soweit ich mich erinnere habe ich die Port Forwarding und Outbound NAT Regeln immer auf die einzelnen Interfaces gemacht.
Wenn zwei PPPoE WAN Verbindungen vom selben ISP die selbe Gateway IP Adresse benutzen.
https://github.com/opnsense/core/issues/5238
Edit: Achso im Schaubild steht Kabel und DSL aber 2 mal PPPoE. Wieder verwirrt worden. Sorry
Ich würde einfach 2 Port Forwarding Regeln anlegen, für jedes WAN interface eine eigene, und schauen ob es dann funktioniert. Wenn diese Regeln auch nicht matchen dann gibt es da irgend ein anderes Problem als die Gateway Gruppe. Vor mehreren Jahren hatte ich auch eine Opnsense an DSL und Kabel gleichzeitig mit Gateway Gruppe betrieben, aber soweit ich mich erinnere habe ich die Port Forwarding und Outbound NAT Regeln immer auf die einzelnen Interfaces gemacht.
1536
German - Deutsch / Re: Port Forward funktioniert nicht; nginx DataStream funktioniert
« on: September 16, 2023, 07:16:49 pm »
Wenn Wireguard auf der OPNsense läuft muss man kein Port Forwarding dafür machen.
Der Port von Wireguard wird auf alle Interfaces gebunden.
Es muss nur eine Firewall Regel erstellt werden, die den Port eingehend auf den WAN Interfaces erlaubt.
Der Port von Wireguard wird auf alle Interfaces gebunden.
Es muss nur eine Firewall Regel erstellt werden, die den Port eingehend auf den WAN Interfaces erlaubt.
1537
23.7 Legacy Series / IPsec and State Synchronization - unexpected behavior
« on: September 15, 2023, 09:08:25 am »
I had this weird behavior between two OPNsense in HA while using IPsec (between DEC hardware and VM with pcie passthrough, all interface names are the same and theres a lagg)
Quite often, I connected an ikev2 ipsec tunnel, phase 1 and phase 2 were up, but there was no traffic from the opnsense back to the remote peer. It always worked the first time, but the second time it didn't. This behavior mostly affected roadwarrior connections with lots of reconnecting and lesser the site2site tunnels.
My troubleshooting led me to State Synchronization. In Sessions I could also see established TCP sessions even though the tunnel was down.
When I deleted the IP Addresses of the traffic selector (e.g. 192.168.0.0/24) from the state table on both firewalls and restarted the ipsec tunnel, it worked again with Tx and Rx.
To mitigate this behavior:
I created extra firewall rules in Firewall: Rules: IPsec which timed out TCP faster (after 600 seconds).
Then I disabled state syncronisation by setting the "State Type / NO pfsync" parameter for all rules in Firewall: Rules: IPsec.
I didn't come to a conclusion, I just know that my mitigations work and all roadwarriors can connect every time now. It would be interesting to know if that's an expected problem between hardware and vm, or if it could theoretically happen between two hardwares too.
Quite often, I connected an ikev2 ipsec tunnel, phase 1 and phase 2 were up, but there was no traffic from the opnsense back to the remote peer. It always worked the first time, but the second time it didn't. This behavior mostly affected roadwarrior connections with lots of reconnecting and lesser the site2site tunnels.
My troubleshooting led me to State Synchronization. In Sessions I could also see established TCP sessions even though the tunnel was down.
When I deleted the IP Addresses of the traffic selector (e.g. 192.168.0.0/24) from the state table on both firewalls and restarted the ipsec tunnel, it worked again with Tx and Rx.
To mitigate this behavior:
I created extra firewall rules in Firewall: Rules: IPsec which timed out TCP faster (after 600 seconds).
Then I disabled state syncronisation by setting the "State Type / NO pfsync" parameter for all rules in Firewall: Rules: IPsec.
I didn't come to a conclusion, I just know that my mitigations work and all roadwarriors can connect every time now. It would be interesting to know if that's an expected problem between hardware and vm, or if it could theoretically happen between two hardwares too.
1538
23.7 Legacy Series / Re: Firewall Diagnostic States not searchable after 23.7.4 upgrade
« on: September 14, 2023, 07:12:16 pm »
I just tested it too and it only shows results when I type full IPv4 or IPv6 addresses. It doesn't show results when there's just partially written ones.
It happens in sessions and in states.
I just tested it on an older version (OPNsense 23.4.2-amd64) too and there partial strings work.
It happens in sessions and in states.
I just tested it on an older version (OPNsense 23.4.2-amd64) too and there partial strings work.
1539
Virtual private networks / Re: IKE v2 - cannot get it to work on latest version
« on: September 13, 2023, 10:11:11 pm »
EDIT: You were right I corrected the mistake.
In pre shared keys the type is EAP and not PSK.
And the username can be anything you want, you can also just use john. In the client it has to be written the same as in the EAP Local Identifier. (So if the eap local identifier is john@fqdn, in the client the username is also john@fqdn)
Self signed certificate should still work if the certificate chain. is in the window certificate store.
Also please verify that your firewall accepts udp 500 and udp 4500 and esp on the WAN port. The new IPsec configurations don't automatically add firewall rules anymore.
I have tested both configurations thoroughly so your feedback is really welcome if you find mistakes somewhere.
In pre shared keys the type is EAP and not PSK.
And the username can be anything you want, you can also just use john. In the client it has to be written the same as in the EAP Local Identifier. (So if the eap local identifier is john@fqdn, in the client the username is also john@fqdn)
Self signed certificate should still work if the certificate chain. is in the window certificate store.
Also please verify that your firewall accepts udp 500 and udp 4500 and esp on the WAN port. The new IPsec configurations don't automatically add firewall rules anymore.
I have tested both configurations thoroughly so your feedback is really welcome if you find mistakes somewhere.
1540
Virtual private networks / Re: IKE v2 - cannot get it to work on latest version
« on: September 13, 2023, 08:28:43 pm »1541
German - Deutsch / Re: Port forward über OpenVPN Tunnel Problem
« on: September 13, 2023, 07:02:30 pm »
Ich habs gerade gelesen als ich das auch vorschlagen wollte weil ich es nachgestellt habe mit einem anderen Interface. Super dass du es geschafft hast.
1542
German - Deutsch / Re: Port forward über OpenVPN Tunnel Problem
« on: September 13, 2023, 05:58:27 pm »
Ich meinte eher ob du in "System: Gateways: Single" das Gateway deines OpenVPN Providers konfiguriert hast.
Und ob du dann in "Firewall: Rules: Mailserver Netzwerks" eine Firewall Regel angelegt hast die so aussieht:
Source: Interne IPv4 Adresse des Mailservers
Destination: Any
Gateway: "OpenVPN Gateway"
Das ist dann sozusagen eine SD-WAN Regel die allen Traffic des Mailservers über das OpenVPN umleitet. Nur Outbound NAT reicht nicht.
Und ob du dann in "Firewall: Rules: Mailserver Netzwerks" eine Firewall Regel angelegt hast die so aussieht:
Source: Interne IPv4 Adresse des Mailservers
Destination: Any
Gateway: "OpenVPN Gateway"
Das ist dann sozusagen eine SD-WAN Regel die allen Traffic des Mailservers über das OpenVPN umleitet. Nur Outbound NAT reicht nicht.
1543
German - Deutsch / Re: Port forward über OpenVPN Tunnel Problem
« on: September 13, 2023, 05:31:27 pm »
Über welches Gateway wird der Mailserver ins WAN geroutet? Wenn in der Firewallregel des Mailservers "default" steht, und das Standardgateway der Opnsense PPPoE0 ist, dann wird der Mailserver Antwortpakete darüber ins WAN senden.
Ich würde dem Mailserver das Gateway des OpenVPN-Providers durch eine extra Firewallregel zuteilen, sodass er alle Antwortpakete über das OpenVPN senden MUSS.
Das vermute ich mal so auf die schnelle, ob es genau auf deinen Fall zutrifft weiß ich nicht, vielleicht hilft es aber.
Ich würde dem Mailserver das Gateway des OpenVPN-Providers durch eine extra Firewallregel zuteilen, sodass er alle Antwortpakete über das OpenVPN senden MUSS.
Das vermute ich mal so auf die schnelle, ob es genau auf deinen Fall zutrifft weiß ich nicht, vielleicht hilft es aber.
1544
High availability / Re: Link-net with CARP and HA
« on: September 13, 2023, 11:05:27 am »
Happens quite often somehow.
Always make sure you seperate layer 2 broadcast domains. (Which means, different switches or different VLANs)
Each IP Network should have its own VLAN or switch for routing to work right. If there are shortcuts on layer 2 with ARP protocol or on layer 3 with ICMP Redirects, you get asynchronous routing which makes TCP fail.
Always make sure you seperate layer 2 broadcast domains. (Which means, different switches or different VLANs)
Each IP Network should have its own VLAN or switch for routing to work right. If there are shortcuts on layer 2 with ARP protocol or on layer 3 with ICMP Redirects, you get asynchronous routing which makes TCP fail.
1545
High availability / Re: Link-net with CARP and HA
« on: September 13, 2023, 10:39:41 am »
I have a suspicion, but to prove it can you create the Floating Any Allow rule. Set the protocol of the rule to "TCP" and at the bottom of the rule "Advanced features", enable "TCP flags - Any flags" and "State Type - Sloppy State".
Then try to connect to a TCP destination, like with ssh, http or https.
Suspicion: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html
Then try to connect to a TCP destination, like with ssh, http or https.
Suspicion: https://docs.netgate.com/pfsense/en/latest/troubleshooting/asymmetric-routing.html