Openvpn und nat / esxi

wondermike

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/24

Diagramm:

[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

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

JeGr

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 Switch

Damit wäre eine korrekte Trennung von WAN/LAN der Fall.

Grüße

wondermike

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

JeGr

@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

@JeGr:

@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.

@JeGr:

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.

JeGr

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

wondermike

@JeGr:

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