Openvpn und nat / esxi
-
Hi ich versuche gerade eine VPN-Verbindung mit pfSense aufzubauen. PfSense läuft innerhalb einer VM unter ESXi. Der Server hat 2 physische nics, die pfSense VM hat 3 logische vnics.
Weitere Elemente:
vswitch #1: (vnic1/LAN/192.168.0.1).
vswitch #2: (vnic2/VPN/x.x.x.241), (vnic3/WAN/192.168.10.11)
Physischer DSL-Router (192.168.10.1)
VM1..n hängen am vswitch1 und haben Adressen im Netz 192.168.0.0/24Diagramm:
[openvpn/server x.x.x.18] | Internet | DSLrouter | [physischer...switch] \_phy...nic1 \_phy...nic2 | | ...vswitch2... ...vswitch1... WAN VPN LAN \ \ \........+...../ VM1...n pfSense
(Hoffe es ist klar wie's gemeint ist)
Es gibt bereits eine openvpn-Verbindung, die ich ja ablösen und nach pfSense migrieren möchte. Deren Konfiguration habe ich mal hier dokumentiert:
verb 4 dev tun1 remote x.x.x.18 ifconfig x.x.x.241 x.x.x.254 lport 6888 rport 6888 tun-mtu 1360 disable-occ ifconfig-nowarn ping 30 secret ....path-to-the-file.../comserv.secret up /etc/openvpn/./comserv.up down /etc/openvpn/./comserv.down script-security 2
in dem up script, mache ich im Kern ein
/sbin/ip route add default dev tun1 table tun1.out /sbin/ip rule add from x.x.x.241 table tun1.out pref 1000 /sbin/ip route flush cache
Diese alte openvpn-Verbindung funktioniert bisher gut, diese möchte ich wie gesagt aber ablösen.
In pfSense habe ich eine openvpn Client configuration angelegt, dies erlaubt mir eine Verbindung von x.x.x.241/32 (lokal/VPN) nach x.x.x.18/32 (für den Login, der remote endpoint hingegen ist x.x.x.254/32) auf den Ports lport/rport 6888. aktuell schaffe ich es unter pfSense, eine P-t-P-Verbindung von x.x.x.241/32 zu x.x.x.254/32 aufzubauen. Funktioniert an sich gut. Mit anderen Worten - die VPN-Verbindung exponiert die x.x.x.241/32 nach außen.
Unter pfSense fülle ich die folgenden Felder im Bereich der openvpn Client-Konfiguration aus:
| Server Mode | Peer-to-Peer (Shared key) |
| Protocol | udp |
| Device Mode | tun |
| Interface | VPN |
| Local Port | 6888 |
| Server host or address | x.x.x.18 |
| Server Port | 6888 |
| Shared Key: | #2048 bit OpenVPN static key
–---BEGIN OpenVPN Static key V1-----
......
-----END OpenVPN Static key V1----- |
| Encryption algorithm | BF-CBC (128 bit) |
| IPv4 Tunnel Network | x.x.x.241/28 |
| IPv4 Remote Network/s | x.x.x.254/32 |
| Advanced: | ifconfig x.x.x.241 x.x.x.254
remote x.x.x.18
tun-mtu 1360
disable-occ
ifconfig-nowarn |Diese Firewall- und NAT-Regeln habe ich definiert:
Proto Source Port Destination Port Gateway Queue Schedule WAN: IPv4* * * * * * none LAN: IPv4* LAN net * * * * none VPN: IPv4* LAN net * * * * none OpenVPN: IPv4* * * x.x.x.241 * * none ``` … NAT:
NAT:
If Proto Src. addr Src. ports Dest. addr Dest. ports NAT IP NAT Ports
OpenVPN TCP * * x.x.x.241 53 (DNS) 192.168.0.a 53 (DNS)
OpenVPN TCP * * x.x.x.241 22 (SSH) 192.168.0.b 22 (SSH)
OpenVPN ICMP * * x.x.x.241 * 192.168.0.c *(a, b und c sind Nummern … das sind VMs) ... usw. ... mit dem letztlichen Ziel, dass bestimmte VMs (a, b and c) auf Anfragen von außen antworten. Hier kommt jedoch das Problem: sobald ein ping oder eine TCP-Verbindung von außen auf der exponierten IP x.x.x.241 ankommt, wird's schwierig. Was mir gelingt: Anfragen werden per NAT-Tabelle an die richtigen VMs weitergeleitet und können dort vom jeweiligen Dienst gelesen/verstanden werden. Die Antwort geht jedoch nicht mehr durch. Ich kann keine blockierten Pakete im Log sehen. Ich kann jedoch sehr wohl sehen, dass die Antworten losgeschickt werden (per tcpdump auf der jeweiligen antwortenden VM, z.B. ICMP echo Replies oder Antworten auf DNS-Anfragen auf Port 53). Keine der Antworten kommt zum Initiator der Verbindung / Kommunikation zurück. Ich habe das Gefühl, dass mir da nur noch ein winziger Baustein zum Glück fehlt. Habt Ihr eine Idee woran es hängen könnte? Danke im Voraus & Gruss Michael
-
Ahoi,
aus deiner Skizze werde ich nicht ganz schlau:
beide physikalischen Interfaces sind auf den gleichen Switch gesteckt und auf je einen vswitch verbunden? Und da läuft dann LAN und WAN drüber? Das ist… sehr schräg. Im Normalfall willst du ja mit der pfSense das Netz schützen, so baust du es aber parallel zum Netz auf und schaffst gleichzeitig noch eine Umgehung?
"Richtig" wäre aus meinem Gefühl eher der Ansatz:
Internet <---> DSL-Router <---> ESX phys.NIC1 (intern direkt auf das WAN der pfSense VM verbunden)
vSwitch (LAN) verbunden mit ESX phys.NIC2 <---> lokaler SwitchDamit wäre eine korrekte Trennung von WAN/LAN der Fall.
Grüße
-
Hi, mir ist schon klar, dass die physikalisch getrennt werden müssen, aber es geht mir erst mal um die Machbarkeit - egal ob getrennt oder nicht, die Kommunikation muss ja in beiden Richtungen durchgehen.
Gruß Michael -
@wondermike: Die Architektur sollte man sich m.E. vorher überlegen und dann umsetzen und nicht erst etwas Bauen was dann solala funktioniert nur "um mal zu schauen" :) Solche Fälle habe ich leider im Job genug, deshalb mein Rat und Bitte, das eben vorher klar zu definieren und dann gleich richtig zu bauen und nicht erst mit Umgehungsleitung um sich später dann irgendwann zu wundern, wie zur Hölle die VM nach außen kommt oder der Eindringling nach drinnen, obwohl die pfS doch zumachen sollte. ;)
Ansonsten erinnert mich das Setup an einen Standard-Hetzner-Rootserver-mit-ESXi Fall, sollte also problem möglich sein. Hatte ich eine zeitlang als Demo-Setup in Betrieb. Intern hatten alle VMs unterschiedliche VLANs abhängig davon, was für einen Job sie hatten (development, prelive, live, showcase), jedes VLAN war als virtual NIC auf die virtuelle pfSense reingereicht, der physikalische Adapter hatte die ESXi Router-IP (die der Hoster eben vorgibt) und war auf die pfSense reingemappt. Klappte tadellos.
Grüße
-
@wondermike: Die Architektur sollte man sich m.E. vorher überlegen und dann umsetzen und nicht erst etwas Bauen was dann solala funktioniert nur "um mal zu schauen" :) Solche Fälle habe ich leider im Job genug, deshalb mein Rat und Bitte, das eben vorher klar zu definieren und dann gleich richtig zu bauen und nicht erst mit Umgehungsleitung um sich später dann irgendwann zu wundern, wie zur Hölle die VM nach außen kommt oder der Eindringling nach drinnen, obwohl die pfS doch zumachen sollte. ;)
Die Gedanken habe ich mir gemacht, zumal ich jahrelang in shorewall unterwegs war und mir die Konzepte schon ein Begriff sind. Vielleicht habe ich mich nicht klar ausgedrückt. Vielleicht war es Bestimmung.
Ansonsten erinnert mich das Setup an einen Standard-Hetzner-Rootserver-mit-ESXi Fall, sollte also problem möglich sein. Hatte ich eine zeitlang als Demo-Setup in Betrieb. Intern hatten alle VMs unterschiedliche VLANs abhängig davon, was für einen Job sie hatten (development, prelive, live, showcase), jedes VLAN war als virtual NIC auf die virtuelle pfSense reingereicht, der physikalische Adapter hatte die ESXi Router-IP (die der Hoster eben vorgibt) und war auf die pfSense reingemappt. Klappte tadellos.
Schön :)
Meine Lösung heißt jetzt allerdings shorewall, da habe ich meinen Bedarf nun komplett abgedeckt bekommen, alle use cases (auch die hier nicht dokumentierten) abgedeckt.
Bye by pfSense - war schön mit Euch. -
Ahoi,
dann hatte ich das vielleicht nicht korrekt verstanden, es klang so, als sollte es "erstmal einfach gehen" und hinterher aussortiert werden obs sinnvoll ist ;)
Nichts desto trotz hätte es sicherlich problemlos funktioniert. Ich muss gestehen ich hatte Shorewall bereits einmal vor langen Jahren im Einsatz und möchte nicht wieder hintauschen. Kein Affront - zumal ich nicht weiß wie gut das Ding heute ist - aber nachdem damals schon simple Dinge wie Failover im Laufenden Betrieb (CARP / VRRP) nicht funktioniert haben, weil nicht möglich, war das leider keine Lösung, die vertretbar war. Zumal auch die Regelsätze teilweise unnötig kompliziert und aufgeblasen waren (im Gegensatz zu pf).Aber so ist es eben, es findet jeder das, was ihm am Besten passt :) Vielleicht treibt es dich für was anderes ja zurück zu pfSense.
Grüße
-
Vielleicht treibt es dich für was anderes ja zurück zu pfSense.
Ich behalte es ganz sicher weiter im Sichtfeld und beobachte die Entwicklung … es gibt immer wieder Leute die nach ner einfach zu administrierenden Lösung Fragen und da ist pfSense ganz vorne mit dabei.
cu