Site to Site VPN mit PfSense - Zugriff auf Remote Netze nicht möglich.

Hallo,

wir haben 2 pfsense Firewalls an unterschiedlichen Standorten. An Standort A stehen unsere Server, an Standort B befinden sich mehrere Clients, die auf die Server zugreifen sollen.

Soweit so gut, OpenVPN installiert und entsprechend eingerichtet (mit Zertifikaten und Pre-Shared-Key), die Verbindung wird auch aufgebaut. Nun können die Clients an Standort B keine Server an Standort A pingen (Pingtimeouts). Über die Firewall über das OpenVPN Interface lassen sich die Server jedoch anpingen (der Tunnel scheint also zu funktionieren).

Die Server befinden sich alle in /31-Netzen und in VLANs gesplittet im 10.0.0.0/8 Netzwerk, die Clients befinden sich in 172.16.224.0/24.

Folgende Konfigurationen:

Server (unter OpenVPN -> Server)
Peer to Peer (SSL/TLS)
tcp
tun
Interface WAN
Port 1194

<Zertifikatseinstellungen>

IPv4 Tunnel Network: 192.168.224.0/24
IPv4 Local Networks: 10.0.0.0/8
IPv4 Remote Networks: 172.16.224.0/24
Provide a virtual adapter IP address to clients (see Tunnel Network).

Client (unter OpenVPN -> Clients)
Peer to Peer (SSL/TLS)
tcp
tun
Interface WAN
Port 1194
Server: Hostname Standort1.example.com (DNS funktioniert entsprechend)

<Zertifikatseinstellungen>

IPv4 Tunnel network: 192.168.224.0/24
IPv4 Remote Networks: 10.0.0.0/8

Als Firewall auf den OpenVPN Interfaces jeweils temporär Any-Any Rules festgelegt, testweise mit Client-Any Rule auf dem LAN Interface an StandortB, an Standort A natürlich auf dem WAN Interface den Port für Standort B freigegeben. In den Firewalllogs tauchen keine Blocks auf.

So weit so gut.

Wenn ich nun von Standort B aus einen Server an Standort A anpingen möchte, dann erscheinen auch ICMP Pakete auf dem OpenVPN Interface auf der lokalen Firewall, auf der Remote Firewall tauchen jedoch keine Pakete auf.

Die Clients auf der lokalen Firewall sehen ca so aus:

Client IP > Server IP_Remote ICMP echo request etc.
Client IP > Server IP_Remote ICMP echo request etc.

Hat jemand einen Hinweis/Tipps?

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 325964

Url: https://administrator.de/contentid/325964

Ausgedruckt am: 24.11.2024 um 16:11 Uhr

6 Kommentare

Neuester Kommentar

Hallo,

Nun können die Clients an Standort B keine Server an Standort A pingen (Pingtimeouts).

Liegt eventuell an den Firewallregeln denn ICMP Pakete soll muss man auch nicht von außerhalb per default akzeptieren
sondern man muss sie per Regel explizit erlauben.

Über die Firewall über das OpenVPN Interface lassen sich die Server jedoch anpingen (der Tunnel scheint also zu funktionieren).

Dort ist dann die regel nicht aktiv, oder?

Die Server befinden sich alle in /31-Netzen

Warum kann man denn nicht auch alles in /24 Netze unterbringen und hat dann einfach weniger Probleme
damit hinter her sowie in so einem Fall hier?

und in VLANs gesplittet im 10.0.0.0/8 Netzwerk, die Clients befinden sich in 172.16.224.0/24.

Dann Regeln anpassen und eventuell noch Routen in diese netze anlegen, sollte dann aber auch passen!

Wenn ich nun von Standort B aus einen Server an Standort A anpingen möchte, dann erscheinen auch ICMP Pakete auf dem
OpenVPN Interface auf der lokalen Firewall, auf der Remote Firewall tauchen jedoch keine Pakete auf.

Per Firewall-Regel erlauben funktioniert hier nicht zufällig auch?

Gruß
Dobby

Hi,

Über die Firewall über das OpenVPN Interface lassen sich die Server jedoch anpingen (der Tunnel scheint also zu funktionieren).

Steht in der Advanced Configuration des Servers ein push "route 10.0.0.0 255.0.0.0"; Eintrag?
...und hast Du denn im OVPN-Server, ausser den Eintrag Deines remoten Netzes auch unter...
Client Specific Overrides einen "iroute" Eintrag stehen?
iroute 172.16.224.0 255.255.255.0;
Gruß orcape

Vermutlich fehlen auch noch die entsprechenden Firewall Regeln für die VPN Interface auf der pfSense...?!
Übrigens TCP für die Tunnelencapsulation zu verwenden ist tödlich !
OpenVPN rät selber dringenst in deren Dokumentation davon ab, denn durch den höheren Overhead sinkt deine Nettodatenrate drastisch. Weiterhin bekommt man erheblich größere Probleme mit MTU und MSS Problemen im Tunnel selber.
Letztendlich geht das alles massiv auf die Durchsatz Performance. Darüber solltest du also dringenst nochmal nachdenken. UDP ist hier wie immer State of the Art...