14
PfSense Firewall mit Multi-WAN: Konflikt zwischen VoIP und IPsec-VPN
Hallo,
ich habe in den letzten Monaten einiges an Erfahrung mit pfSense sammeln können, zum einen was IPsec-VPNs mit Fritzbox-Gegenstellen und zum anderen was die VoIP-Konfiguration angeht (Telekom VoIP) an einer Fritzbox hinter der pfSense. Dank der sehr guten Anleitungen hier im Forum funktioniert beides super... allerdings nur entweder die VoIP-Telefonie (hinter der pfSense) ODER die VPN-Funktion der pfSense... Mit anderen Worten ich habe offenbar ein Problem mit der Firewall-Konfiguration, genauer gesagt dem Outbound NAT.
Um VoIP hinter der pfSense nutzen zu können hatte ich pfSense folgendermaßen konfiguriert:
Und natürlich keep-alive bzw. re-registration an der Fritzbox auf den kleinsten Wert, 30 Sekunden (aber das tut für dieses Posting hier nichts zur Sache).
Mein Problem ist, dass sobald ich den/die statischen Port/s beim Outbound NAT aktiviere, mein VPN nicht mehr funktioniert.
Deaktiviere ich es, klingelt das IP-Telefon zwar noch, Audio bleibt aber in beiden Richtungen stumm. Der Konflikt ist nicht weiter verwunderlich, IPsec-VPNs brauchen ja die UDP-Ports 500 (ISAKMP) und ggf. 4500 (NAT-T). Was ich als Abhilfe probiert habe: Unter Firewall / Aliases / Ports einen Alias eintragen:
Und diesen Alias anschließend dann einfach beim Outbound NAT eingetragen, um das statische Mapping nicht für alle Ports zu haben, sondern nur für die im Alias angegebenen. Aber das hat leider nichts geholfen bzw. geändert... Habe ich einen Denkfehler? Wäre echt toll, wenn ihr mir auf die Sprünge helfen könntet.
ich habe in den letzten Monaten einiges an Erfahrung mit pfSense sammeln können, zum einen was IPsec-VPNs mit Fritzbox-Gegenstellen und zum anderen was die VoIP-Konfiguration angeht (Telekom VoIP) an einer Fritzbox hinter der pfSense. Dank der sehr guten Anleitungen hier im Forum funktioniert beides super... allerdings nur entweder die VoIP-Telefonie (hinter der pfSense) ODER die VPN-Funktion der pfSense... Mit anderen Worten ich habe offenbar ein Problem mit der Firewall-Konfiguration, genauer gesagt dem Outbound NAT.
Um VoIP hinter der pfSense nutzen zu können hatte ich pfSense folgendermaßen konfiguriert:
- Conservative state table optimization (System / Advanced / Firewall & NAT: Firewall Optimization Options: Conservative)
- Disable source port rewriting
- Firewall / NAT / Outbound: Hybrid Outbound NAT rule generation
- Static port on all UDP traffic potentially with the exclusion of UDP 5060 (ich habe den statischen Port bislang allerdings für ALLE Source-Ports, auch für 5060)
Und natürlich keep-alive bzw. re-registration an der Fritzbox auf den kleinsten Wert, 30 Sekunden (aber das tut für dieses Posting hier nichts zur Sache).
Mein Problem ist, dass sobald ich den/die statischen Port/s beim Outbound NAT aktiviere, mein VPN nicht mehr funktioniert.
Deaktiviere ich es, klingelt das IP-Telefon zwar noch, Audio bleibt aber in beiden Richtungen stumm. Der Konflikt ist nicht weiter verwunderlich, IPsec-VPNs brauchen ja die UDP-Ports 500 (ISAKMP) und ggf. 4500 (NAT-T). Was ich als Abhilfe probiert habe: Unter Firewall / Aliases / Ports einen Alias eintragen:
Und diesen Alias anschließend dann einfach beim Outbound NAT eingetragen, um das statische Mapping nicht für alle Ports zu haben, sondern nur für die im Alias angegebenen. Aber das hat leider nichts geholfen bzw. geändert... Habe ich einen Denkfehler? Wäre echt toll, wenn ihr mir auf die Sprünge helfen könntet.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 325058
Url: https://administrator.de/contentid/325058
Printed on: April 26, 2024 at 04:04 o'clock
14 Comments
Latest comment
Hallo,
du sprichst zwar von den Ports 500 und 4500 aber hast du auch das IP Protokoll 50 freigegeben?
Gruß
du sprichst zwar von den Ports 500 und 4500 aber hast du auch das IP Protokoll 50 freigegeben?
Gruß
allerdings nur entweder die VoIP-Telefonie (hinter der pfSense) ODER die VPN-Funktion der pfSense...
Eigentlich Unsinn, den beide Anwendeung sind grundverschieden und haben nicht das Geringste miteinander zu tun. Logisch, denn sie nutzen beide vollkommen unterschiedliche TCP und UDP Ports oder Protokolle.Zeigt eigentlich eher das du einen grundlegenden Fehler in der Konfiguration gemacht hast ?!
Mit anderen Worten ich habe offenbar ein Problem mit der Firewall-Konfiguration, genauer gesagt dem Outbound NAT.
Das kann man wohl sagen....Um VoIP hinter der pfSense nutzen zu können hatte ich pfSense folgendermaßen konfiguriert:
Wie das genau geht kannst du im hiesigen Tutorial in den weiterführenden Links nachlesen (VoIP bzw. Telefonie mit FritzBox oder Anlage hinter pfSense Firewall)IPsec-VPNs brauchen ja die UDP-Ports 500 (ISAKMP) und ggf. 4500 (NAT-T)
Richtig !Allerdings den Hauptteil hast du hier unterschlagen und das ist ESP !!! (IP Protokoll Nr. 50) ESP ist ein eigenständiges IP Protokoll und der ESP Tunnel transportiert die Produktivdaten bei IPsec.
Es ist klar und logisch das du natürlich UDP 500 und 4500 aus einer ggf. vorhandenen Portrange ausklammern musst sofern du diese für RTP (VoIP) definiert hast !! So groß muss die RTP Portrange auch niemals sein !! (Siehe Tutorial)
Audio bleibt aber in beiden Richtungen stumm.
Zeigt das SIP (TCP 5060) zwar durchkommt aber RTP (Voice) eben nicht. Hier ist also ein Fehler beim RTP Forwarding !Habe ich einen Denkfehler?
Das steht zu vermuten....Eigentlich musst du nur SIP forwarden und die RTP Portrange, da RTP dynamische Ports benutzt beim Sessionaufbau.
Noch sinnvoller ist mit einem VoIP STUN Proxy zu arbeiten, dann kann man sich den ganzen Aufwand eh sparen, das muss aber auch dein VoIP Provider supporten !
Ein gutes Neues erstmal 
Da ich wie im Eingangsposting "Firewall / NAT / Outbound: Hybrid Outbound NAT rule generation" aktiviert hatte, also den hybriden Modus, ging ich davon aus, dass unter "Firewall / NAT / Outbound" die "Auto created rule for ISAKMP" (UDP port 500) greifen würde. Ich habe testweise zusätzlich das Protokoll ESP erlaubt (von any zu any), gelb markiert im Screenshot unten, aber das hilft bislang nicht, VPN geht so auf dem Interface WANDTAG leider nicht.
Ich habe außerdem bei den Aliasen für VoIP die Ports auf die für die Fritzbox notwendigen Ports reduziert:
Da ich wie im Eingangsposting "Firewall / NAT / Outbound: Hybrid Outbound NAT rule generation" aktiviert hatte, also den hybriden Modus, ging ich davon aus, dass unter "Firewall / NAT / Outbound" die "Auto created rule for ISAKMP" (UDP port 500) greifen würde. Ich habe testweise zusätzlich das Protokoll ESP erlaubt (von any zu any), gelb markiert im Screenshot unten, aber das hilft bislang nicht, VPN geht so auf dem Interface WANDTAG leider nicht.
Ich habe außerdem bei den Aliasen für VoIP die Ports auf die für die Fritzbox notwendigen Ports reduziert:
Vollkommen unverständlich was du mit deinen ominösen Mappings und verschrubelten NAT Rules usw. da alles verschlimmbesserst....
Das Einzige was man braucht um IPsec zum Fliegen zu bringen auf der pfSense ist eine simple Firewall Regel auf dem WAN Interface !
Das geht ganz einfach unter Firewall --> Rules --> WAN und sieht dann so aus wie der Screenshot unten.
Das hier sind die Regeln die du für simples IPsec auf den WAN Port installieren musst:
Wenn man es richtig macht sieht das im Firewall Ruleset am WANDTAG Port dann so aus:
Damit rennt das fehlerfrei wie dir dieses Forums Tutorial es ja auch beweist:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Sieh doch einfach mal ins Firewall Log UND ins IPsec Log !!!
Da steht doch bei VPN Zugriff genau protokolliert wenn die FW Regeln IPsec blocken sollten oder was mit der IPsec Negotiation passiert bei VPN Zugriff !!
Was steht denn da ???
Setz dir das in den Settings am besten so das du die aktuellsten Log Messages immer gleich oben siehst:
Und lösch das Log der Übersicht halber vorher wenn du den VPN Zugriff mitprotokollierst.
Das Einzige was man braucht um IPsec zum Fliegen zu bringen auf der pfSense ist eine simple Firewall Regel auf dem WAN Interface !
Das geht ganz einfach unter Firewall --> Rules --> WAN und sieht dann so aus wie der Screenshot unten.
Das hier sind die Regeln die du für simples IPsec auf den WAN Port installieren musst:
- UDP 500 erlauben von Source: any auf die Destination: WAN IP Adresse.
- UDP 4500 erlauben von Source: any auf die Destination: WAN IP Adresse.
- ESP Protokoll erlauben von Source: any auf die Destination: WAN IP Adresse.
Wenn man es richtig macht sieht das im Firewall Ruleset am WANDTAG Port dann so aus:
Damit rennt das fehlerfrei wie dir dieses Forums Tutorial es ja auch beweist:
IPsec VPN Praxis mit Standort Vernetzung Cisco, Mikrotik, pfSense, FritzBox u.a
Sieh doch einfach mal ins Firewall Log UND ins IPsec Log !!!
Da steht doch bei VPN Zugriff genau protokolliert wenn die FW Regeln IPsec blocken sollten oder was mit der IPsec Negotiation passiert bei VPN Zugriff !!
Was steht denn da ???
Setz dir das in den Settings am besten so das du die aktuellsten Log Messages immer gleich oben siehst:
Und lösch das Log der Übersicht halber vorher wenn du den VPN Zugriff mitprotokollierst.
Danke für die Firewall-Rules und die Hinweise zu den Logs. So wie beschrieben hatte ich diese eigentlich auch schon ausprobiert, ohne Erfolg. ABER (und das ist jetzt vielleicht etwas peinlich!): Wenn man bei der Problembeschreibung aus Vereinfachungsgründen Dinge weglässt (weil man meint sie wären für die Fragestellung unbedeutend), dann rächt sich das immer ab einem gewissen Punkt. Ich hatte VPN und VoIP fast gleichzeitig hinzugefügt (VoIP nur auf WANDTAG) und war danach so sehr auf die Firewallregeln als Problemursache fokussiert, dass ich das Vernetzungsszenario als solches aus dem Blick verloren und vergessen habe es nochmal hinterfragen. Ich muss deshalb noch kurz was zu meinem Aufbau ergänzen, also wie ich mir die pfSense bislang so vorgestellt hatte:
2x WAN port (WANDTAG, WANVODA) ----- > 3x Lan
Lan A 192.168.10.0
Lan B 192.168.11.0 (VPN zur entfernten Site 192.168.2.0, via WANDTAG)
Lan C 192.168.12.0 (VPN zur entfernten Site 192.168.2.0, via WANVODA)
Die pfSense hat also zwei WAN und drei LAN Subnets, die entfernte Site hat nur ein LAN und ein Subnet (es handelt sich dort aber auch nicht um eine pfSense, sondern um eine Fritzbox). Zwischen 192.168.2.0 und 192.168.11.0 sowie zwischen 192.168.2.0 und 192.168.12.0 habe ich jeweils eine eigene Phase 1 und eigene Phase 2 eingerichtet. Eigentlich hatten beide Tunnel funktioniert, bis mir heute auffiel, dass das nicht immer so ist. Wenn die pfSense in der Rolle als IKEv1 responder ist scheint es einfacher zu sein beide Tunnel verbunden zu bekommen, zumindest wenn man von der Fritzbox aus die Verbindung initiiert.
Ich dachte die Subnet-Adressen wären eindeutig genug... Muss man für ein solches Vorhaben eine zweite pfSense anschaffen? Dass manchmal der eine und manchmal der andere Tunnel funktioniert liegt eher nicht an der Firewall?
2x WAN port (WANDTAG, WANVODA) ----- > 3x Lan
Lan A 192.168.10.0
Lan B 192.168.11.0 (VPN zur entfernten Site 192.168.2.0, via WANDTAG)
Lan C 192.168.12.0 (VPN zur entfernten Site 192.168.2.0, via WANVODA)
Die pfSense hat also zwei WAN und drei LAN Subnets, die entfernte Site hat nur ein LAN und ein Subnet (es handelt sich dort aber auch nicht um eine pfSense, sondern um eine Fritzbox). Zwischen 192.168.2.0 und 192.168.11.0 sowie zwischen 192.168.2.0 und 192.168.12.0 habe ich jeweils eine eigene Phase 1 und eigene Phase 2 eingerichtet. Eigentlich hatten beide Tunnel funktioniert, bis mir heute auffiel, dass das nicht immer so ist. Wenn die pfSense in der Rolle als IKEv1 responder ist scheint es einfacher zu sein beide Tunnel verbunden zu bekommen, zumindest wenn man von der Fritzbox aus die Verbindung initiiert.
Ich dachte die Subnet-Adressen wären eindeutig genug... Muss man für ein solches Vorhaben eine zweite pfSense anschaffen? Dass manchmal der eine und manchmal der andere Tunnel funktioniert liegt eher nicht an der Firewall?
Bei Dual WAN ist es wichtig das du die IPsec Verbindung vom Balancing ausnimmst ! Balancing darf es da nicht geben, denn sonst vermutet IPsec sofort einen "Man in the middle" und terminiert die Tunnelverbindung.
Du musst also die IPsec Verbindungen einfach ausnehmen und auf die entsprechend LAN Ports festnageln.
Das du das vermutlich nicht gemacht hast zeigt das der Tunnel mal geht und mal nicht.
Typisches Verhalten wenn die IPsec Konfig falsch ist bzw. mitgebalanced wird.
Ein 2te pfSense braucht man dafür natürlich nicht...keine Frage !
Du musst also die IPsec Verbindungen einfach ausnehmen und auf die entsprechend LAN Ports festnageln.
Das du das vermutlich nicht gemacht hast zeigt das der Tunnel mal geht und mal nicht.
Typisches Verhalten wenn die IPsec Konfig falsch ist bzw. mitgebalanced wird.
Ein 2te pfSense braucht man dafür natürlich nicht...keine Frage !
Meine beiden Phasen 1 hatte ich von Anfang an unter "Interface" den jeweiligen WAN-Interfaces zugewiesen, die Phasen 2 unter "Local Network" den jeweiligen LAN subnets.
IPsec-Verbindungen kann ich nicht ausnehmen, da ich keine Gateway Groups eingerichtet habe, korrekt? Darum wollte ich mich später kümmern.
Unter "System / Routing / Gateways" ist beim Gateway WANDTAG_PPPOE der Haken bei "Default Gateway" gesetzt. Ebenso ist der Haken auch beim Gateway WANDTAG_DHCP6 gesetzt, welches ebenfalls existiert, weil ich nebenbei IPv6 mit eingetragen hatte.
Beim Gateway WANVODA_PPPOE habe ich den Haken nicht gesetzt... ich ging irgendwie nicht davon aus, dass man mehr als ein Default-Gateway gleichzeitig haben kann... eins für IPv4 und noch eins für IPv6 - oder mehr?
Lässt sich der Haken bei allen Gateways gleichzeitig setzen? Wie viele Default Gateways sollte/darf ich denn haben, um IPsec nicht zu stören (oder spielt das keine Rolle)? Und benötige ich Gateway Groups? Die schienen mir bisher nicht notwendig - zumindest nicht mit Blick auf IPsec.
IPsec-Verbindungen kann ich nicht ausnehmen, da ich keine Gateway Groups eingerichtet habe, korrekt? Darum wollte ich mich später kümmern.
Unter "System / Routing / Gateways" ist beim Gateway WANDTAG_PPPOE der Haken bei "Default Gateway" gesetzt. Ebenso ist der Haken auch beim Gateway WANDTAG_DHCP6 gesetzt, welches ebenfalls existiert, weil ich nebenbei IPv6 mit eingetragen hatte.
Beim Gateway WANVODA_PPPOE habe ich den Haken nicht gesetzt... ich ging irgendwie nicht davon aus, dass man mehr als ein Default-Gateway gleichzeitig haben kann... eins für IPv4 und noch eins für IPv6 - oder mehr?
Lässt sich der Haken bei allen Gateways gleichzeitig setzen? Wie viele Default Gateways sollte/darf ich denn haben, um IPsec nicht zu stören (oder spielt das keine Rolle)? Und benötige ich Gateway Groups? Die schienen mir bisher nicht notwendig - zumindest nicht mit Blick auf IPsec.
Hier findest du das haarklein erklärt welche Haken du setzen musst und welche nicht:
https://www.heise.de/ct/ausgabe/2016-24-pfSense-als-Load-Balancer-345834 ...
https://www.heise.de/ct/ausgabe/2016-24-pfSense-als-Load-Balancer-345834 ...
Danke - der Heise-Artikel hat mich dem Ziel zwei funktionierende VPN-Verbindungen zu haben, aber nicht näher gebracht - das meiste davon wusste ich. Erkennt man denn aus dem IPsec-Log etwas? Wenn der WANVODA-Tunnel steht, wiederholt sich im IPSec-Log folgendes Muster bezüglich des zweiten, nicht aufbaubaren WANDTAG-Tunnels immer wieder:
Hast Du eine Vermutung was das konkret sein könnte? IPsec Troubleshooting hat mir da leider nicht weitergeholfen. Manchmal geht für ein paar Minuten auch gar kein Tunnel aufzubauen. Und igb0 ist übrigens ein anderes (drittes) LAN Subnet, das mit dem IPSec-VPN eigentlich nichts zu tun hat - keine Ahnung warum es im IPSec-Log auftaucht!
Hast Du eine Vermutung was das konkret sein könnte? IPsec Troubleshooting hat mir da leider nicht weitergeholfen. Manchmal geht für ein paar Minuten auch gar kein Tunnel aufzubauen. Und igb0 ist übrigens ein anderes (drittes) LAN Subnet, das mit dem IPSec-VPN eigentlich nichts zu tun hat - keine Ahnung warum es im IPSec-Log auftaucht!
aber nicht näher gebracht - das meiste davon wusste ich.
Mmmhhh...komisch. Rennt hier auf 2 pfSense'en mit APU Board fehlerlos mit IPsec VPNs.Wichtig eben nur das IPsec auf den entsprechenden Port festgenagelt ist. Das darf natürlich nicht gebalanced werden.
Und Du hast also im Gegensatz zu mir auf der Gegenseite auch eine pfSense, aber (wie die Fritzbox) mit nur einem WAN und einem LAN-Subnet, in das beide VPN-Tunnel münden? Ich habe so das Gefühl ich sei der erste, der eine Konfiguration ausprobiert "IPSec-VPN von Dual-WAN pfSense zu Single-WAN-Fritzbox".
Nachdem die Fritzbox den ersten Tunnel aufgebaut hat, meldet sie bei dem Versuch den zweiten aufzubauen übrigens:
IKE-Error 0x2020 "hash mismatch in received packet"
Für mich sieht das so aus als würde die pfSense was Falsches an die FB senden. So ist die Konfiguration:
In der Fritzbox:
phase1ss = "alt/aes/sha";
...
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
Nachdem die Fritzbox den ersten Tunnel aufgebaut hat, meldet sie bei dem Versuch den zweiten aufzubauen übrigens:
IKE-Error 0x2020 "hash mismatch in received packet"
Für mich sieht das so aus als würde die pfSense was Falsches an die FB senden. So ist die Konfiguration:
In der Fritzbox:
phase1ss = "alt/aes/sha";
...
phase2ss = "esp-aes256-3des-sha/ah-no/comp-lzs-no/pfs";
Mal zwei Zwischenfragen dazu, wenn erlaubt;
Gruß
Dobby
Mmmhhh...komisch. Rennt hier auf 2 pfSense'en mit APU Board fehlerlos mit IPsec VPNs.
Welche Version von pfSense ist das denn?Wichtig eben nur das IPsec auf den entsprechenden Port festgenagelt ist. Das darf natürlich nicht gebalanced werden.
Und wenn man ein Dual WAN Load Balancing hat, ginge es dann trotz alledem noch?Gruß
Dobby
Welche Version von pfSense ist das denn?
Die aktuelle 2.3.2p1Und wenn man ein Dual WAN Load Balancing hat, ginge es dann trotz alledem noch?
Ja, natürlich. Über die Klassifizierungs regel nimmst du ja nur IPsec raus aus dem Balancing. Alles andere balanced natürlich weiter.
1