(gelöst) Kein Zugriff per OpenVPN auf remotes WAN-Interface

orcape

Hi Leute,
und allen erst einmal ein gesundes und erfolgreiches Neues Jahr.
Nun zu meinem Problem, bei folgendem Konstrukt…..
Bei mir....
1&1 DSL mit Fritzbox7490, statische IP 192.168.219.1 Portforwarding 1194-1196
APU2C4 mit pfSense, 2.3.2-RELEASE-p1
WAN statische IP 192.168.219.2, DNS-Forwarder aktiviert
Automatic Outbound-NAT
LAN statische IP 192.168.155.1 Netz 192.168.155.0/24
DMZ+WLAN-Interfaces andere private Netze.

Auf der pfSense laufen 3 OpenVPN-Server Port 1194-1196 ohne Probleme.
Das remote LAN/WLAN-Netz ist bei allen Tunneln erreichbar.

Bei Gegenstelle OVPN-Tunnel 2, Netz 10.12.7.0/24 (Port 1195), ähnliche config...

1&1 DSL mit Fritzbox7412, statische IP kein Portforwarding
ALIX2D13 mit pfSense, 2.3.2-RELEASE-p1
WAN statische IP 192.168.1.2, DNS-Forwarder aktiviert
Automatic Outbound-NAT
LAN statische IP 192.168.18.1 Netz 192.168.18.0/24
DMZ+WLAN-Interfaces andere private Netze.

Auf dieser pfSense läuft der OpenVPN-Client.

Tunnel 2 läuft ohne Fehlermeldungen und ich komme zu Wartungszwecken von meinem PC,
192.168.155.2 problemlos auf die remote pfSense, deren LAN, WLAN, DMZ, so wie es deren Regelwerk vorsieht.

Mein Problem, wenn ich an Standort 2 an einem PC 192.168.18.2 sitze, komme ich auf den GUI der Fritzbox/Port80. Was mir, leider trotz der entsprechenden Routen Angaben im OpenVPN-Server und iroute-Einträgen unter CSC Overrides, sowie der entsprechenden Firewall-Rules über von zu Hause aus, verwehrt bleibt.

In den Logs ist ausser einer geblockten WAN-Verbindung IGMP nichts verwertbares erkennbar.

 	Jan 1 10:30:58 	WAN 	192.168.1.1		224.0.0.1		IGMP

Traceroute bricht am Tunnelende 10.12.7.2 ab, da wohl die Pings an der Fritte geblockt werden.

nmap -v -Pn -p 80 192.168.1.1 liefert folgendes Ergebnis…

root@orca:/#nmap -v -Pn -p 80 192.168.1.1

Starting Nmap 7.31 ( https://nmap.org ) at 2017-01-01 10:44 CET
Initiating Parallel DNS resolution of 1 host. at 10:44
Completed Parallel DNS resolution of 1 host. at 10:44, 0.04s elapsed
Initiating SYN Stealth Scan at 10:44
Scanning 192.168.1.1 [1 port]
Completed SYN Stealth Scan at 10:44, 2.06s elapsed (1 total ports)
Nmap scan report for 192.168.1.1
Host is up.
PORT   STATE    SERVICE
80/tcp filtered http

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 2.19 seconds
           Raw packets sent: 2 (88B) | Rcvd: 0 (0B)

Hilft hier vielleicht ein Portforwarding in der Fritte, um den GUI zu erreichen???
Das hatte ich nicht probiert. :-
Gruß orcape

flix87

Wenn die Routen und Regeln im VPN stimmen wird es wohl an den routen in der FritzBox liegen.
Für die FritzBox an der Gegenstelle gibt es ein Default Gateway was das vom Provider sein drüfte.
Nun kennt seine FritzBox das Netz bei dir daheim nicht und schickt es wohl an das Default Gateway.

Du musst daher für das Netz bei dir Zuhause bei der Fritzbox an der Gegestelle eine Route eintragen die auf die PfSense an der Gegenstelle verweist.
Dann sollte das gehen.

Alternativ dazu könnte man auch mit Outboud NAT die IP Adresse umsetzen aber schöner ist natürlich das mit Routen zu machen wenn es geht.

orcape

Hi flix,
Danke für Deinen Hinweis mit den Routen in der remoten Fritte.
Werde ich mal versuchen, so denn die 7412 das überhaupt mit sich machen lässt.
Gruß orcape

orcape

Hi,
und noch mal zum Thema, da leider noch offen.:-(
Ich habe auf remote des Tunnel 1 einen Linksys E4200v2 mit OpenWRT als OpenVPN_Client im Einsatz.
Nun habe ich auf dem OpenVPN-Server 1 die gleichen Einstellungen vorgenommen wie bei Tunnel 2.
Gleiche Konstellation, Fritzbox7412 1&1 dahinter der OpenWRT-Router.
Keine statisch Route in der Fritte, bin auf Anhieb auf dem GUI der Fritte.
Kann also eigentlich nur eine Einstellungsfrage auf dem pfSense-Client der Gegenstelle sein.
Gruß orcape

viragomann

Hi,
dann lies noch mal, was flix87 im letzten Satz als Alternative zu den Routen geschrieben hat. Vermutlich macht der Router genau dies standardmäßig.
Übrigens macht auch die pfsense das, soweit ich weiß, bei Peer-to-Peer OpenVPN standardmäßig, könnte aber aus verschiedenen Gründen hier nicht passiert sein.

Also gehe in die Outbound NAT Konfig und stelle den Modus auf hybrid oder manuell, falls er auf Automic steht.
Füge eine Regel hinzu: Interface=WAN, Source=<dein netz,="" aus="" dem="" zu="" zugreifst="">, der Rest bleibt auf den Standardwerten (Translation=Interface address), einen passenden Namen vergeben und speichern.

Weniger schön ist diese Lösung, weil damit auf der FB nicht eindeutig erkennbar ist, wer darauf zugreift, ist aber bei den ganzen "Hauptsache-es-geht"-Firewalls und -Router auch Standard.

Grüße</dein>

orcape

Hi,

Also gehe in die Outbound NAT Konfig und stelle den Modus auf hybrid oder manuell, falls er auf Automic steht.

Danke an Euch beide. Das war es, Modus Hybrid, NAT-Regel hinzugefügt und funktioniert.
Gruß orcape