Beantwortet: pfsense - Problem mit dem Monitoring von VPN Gateways

alberich

Member
Hallo Perfect Privacy Team,

nachdem mein pfsense Router bis vor ca. 2 Monaten mit 4 konfigurierten VPN Klients ohne Probleme lief, in der Sommerzeit von mir wenig beachtet wurde, mußte ich jetzt feststellen, dass sich da so einiges bei Euch geändert hat.

Erstmal Gratulation zu dem sehr schön aufgemachten Webauftritt, und siehe da, hier stand ja auch alles, was so bei Euch passiert ist.

Also in pfsense alle Keys und Zertifikate raus und durch die neuen Zertifikate und Keys ersetzen, den einen oder den anderen VPN Server aktualisieren und siehe da, alle meine 4 VPN Klients kommen auf der pfsense wieder hoch und sind online.

Jetzt aber das Problem: Das Monitoring der VPN Gateways erfolgt bei der pfsense durch ein einfaches ICMP echo request, welches früher bei Euch ohne Probleme von den Gateways beantwortet wurde. Das Monitoring wird bei pfsense für zwei Dinge benötigt:

1. Failover der VPN Gateways innerhalb einer Gruppe.
2. Darstellung des VPN Gateways Status in einem Dashboard.

Offensichtlich blockieren die VPN Gateways aber den ICMP echo request, denn die pfsense bekommt keine Antwort und daher werden die VPN Gateways im Dashboard fälschlicherweise als "offline" gekennzeichnet. Weiterhin ist die Funktion des Failover ebenfalls dadurch gestört.

Anbei drei Screenshots von meiner pfsense.

Könnt Ihr meinem Problem folgen?
 
Hallo,

gerade getestet und das Gateway ist Pingbar. Sollte doch ausreichen. Oder? Habe das gerade auf Gigabit CH getestet. Dort ist das Gateway 10.24.11.1
 
Nun, die 1-er Addressen (x.x.x.1) sind pingbar, dass stimmt. Das Problem ist aber, das meine VPN Klienten auf pfsense eine virtuelle Addresse UND eine Gateway Addresse vom VPN Server zugeordnet bekommen, auf die ich keinen Einfluß habe. In meinem Beispiel oben (vgl. Screenshot #3), bekomme ich für Gigabit-NL (VPN4) die Addresse 10.16.21.42 zugeordnet und als Gateway dazu passend 10.16.21.41. Und diese Addresse ist eben nicht pingbar.
 
Hm.. also du hast recht, lässt sich nicht pingen.. Das das vorher mal gegangen sein soll ist aber auch komisch. An der config dafür ist nichts geändert worden, ich hab gerade nochmal die firewall rules durchgeschaut und ein bischen debuggt, selbst ohne iptables rules auf meinem testserver ist das nicht pingbar. Sicher das das mal ging? Falls ja könnte es evtl an ner neueren openvpn version liegen, evtl hat die andere defaults oder irgendwas. Ich teste da jetzt nochmal bischen dran rum, und sonst frag ich mal auf der openvpn mailingliste wie das gedacht ist.

Grüße
Lars
 
Hallo Lars,
sorry für die späte Antwort, ich habe noch soviele andere "Baustellen" im Büro.

Also ich bin mir sehr sicher, dass das mal funktioniert hat und zwar VOR Euren Umstellungen. Da ich meine virtuelle Installation von pfsense und einem dahinter sitzenden, ebenfalls virtuellen, Windows System nicht immer kontrolliert habe, kann ich nicht so genau sagen, ab wann es nicht mehr funktioniert hat.

Der OpenVPN Klient auf der pfsense (2.1-RC1) checked via ping halt nur das Ende des Tunnels, aber nicht die vom OpenVPN Server gelieferte Router Addresse (10.x.x.1).

Damit mir das Routing nicht durch jeden VPN Klient "verbogen" wird, muss ich mit dem Parameter "route-nopull" arbeiten, da ich insgesamt 4 VPN Klients aufgesetzt habe und das Routing durch entsprechende Firewall Rules in der pfsense ersetze. So wurde es auch in einigen Foren vorgeschlagen. Und hat ja auch funktioniert ... ;-)

Folgende zusätzliche Parameter verwende ich u.a.:
ns-cert-type server;persist-remote-ip;tun-mtu 1500;fragment 1300;mssfix;float;reneg-sec 86400;route-method exe;route-delay 2;tls-timeout 5;hand-window 120;inactive 604800;replay-window 512 60;mute-replay-warnings;auth-user-pass /conf.default/PerfectPrivacy.pas;route-nopull;mute 5;script-security 2;verb 5

Hier mal ein Auszug aus meinem OpenVPN log am Beispiel des Gigabit-NL Klienten:
Sep 13 10:31:24openvpn[45354]: MANAGEMENT: Client disconnected
Sep 13 10:31:24openvpn[45354]: MANAGEMENT: CMD 'status 2'
Sep 13 10:31:24openvpn[45354]: MANAGEMENT: CMD 'state 1'
Sep 13 10:31:24openvpn[45354]: MANAGEMENT: Client connected from /var/etc/openvpn/client4.sock
Sep 13 10:31:20openvpn[45354]: Initialization Sequence Completed
Sep 13 10:31:17openvpn[45354]: /usr/local/sbin/ovpn-linkup ovpnc4 1500 1562 10.16.21.70 10.16.21.69 init
Sep 13 10:31:17openvpn[45354]: /sbin/ifconfig ovpnc4 10.16.21.70 10.16.21.69 mtu 1500 netmask 255.255.255.255 up
Sep 13 10:31:17openvpn[45354]: do_ifconfig, tt->ipv6=1, tt->did_ifconfig_ipv6_setup=0
Sep 13 10:31:17openvpn[45354]: TUN/TAP device /dev/tun4 opened
Sep 13 10:31:17openvpn[45354]: TUN/TAP device ovpnc4 exists previously, keep at program end
Sep 13 10:31:17openvpn[45354]: OPTIONS IMPORT: --ifconfig/up options modified
Sep 13 10:31:17openvpn[45354]: OPTIONS IMPORT: timers and/or timeouts modified
Sep 13 10:31:17openvpn[45354]: Options error: option 'route' cannot be used in this context ([PUSH-OPTIONS])
Sep 13 10:31:17openvpn[45354]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Sep 13 10:31:17openvpn[45354]: Options error: option 'dhcp-option' cannot be used in this context ([PUSH-OPTIONS])
Sep 13 10:31:17openvpn[45354]: Options error: option 'redirect-gateway' cannot be used in this context ([PUSH-OPTIONS])
Sep 13 10:31:17openvpn[45354]: PUSH: Received control message: 'PUSH_REPLY,redirect-gateway def1,dhcp-option DNS 95.143.195.140,dhcp-option DNS 115.187.74.91,route 10.16.21.1,topology net30,ping 10,ping-restart 120,ifconfig 10.16.21.70 10.16.21.69'
Sep 13 10:31:17openvpn[45354]: SENT CONTROL [server]: 'PUSH_REQUEST' (status=1)
Sep 13 10:31:14openvpn[45354]: [server] Peer Connection Initiated with [AF_INET]31.204.153.94:1149
Sep 13 10:31:14openvpn[45354]: 3 variation(s) on previous 5 message(s) suppressed by --mute
Sep 13 10:31:14openvpn[45354]: NOTE: --mute triggered...
Sep 13 10:31:14openvpn[45354]: Data Channel Encrypt: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 13 10:31:14openvpn[45354]: Data Channel Encrypt: Cipher 'AES-256-CBC' initialized with 256 bit key
Sep 13 10:31:13openvpn[45354]: VERIFY OK: depth=0, C=NZ, ST=Wellington, O=perfect-privacy, CN=server, emailAddress=admin@perfect-privacy.com
Sep 13 10:31:13openvpn[45354]: VERIFY OK: nsCertType=SERVER
Sep 13 10:31:13openvpn[45354]: VERIFY OK: depth=1, C=NZ, ST=Wellington, L=Johnsonville, O=perfect-privacy, CN=perfect-privacy, emailAddress=admin@perfect-privacy.com
Sep 13 10:31:12openvpn[45354]: WARNING: this configuration may cache passwords in memory -- use the auth-nocache option to prevent this
Sep 13 10:31:12openvpn[45354]: TLS: Initial packet from [AF_INET]31.204.153.94:1149, sid=28c07161 84534830
Sep 13 10:31:12openvpn[45354]: UDPv4 link remote: [AF_INET]31.204.153.94:1149
Sep 13 10:31:12openvpn[45354]: UDPv4 link local (bound): [AF_INET]192.168.112.2
Sep 13 10:31:12openvpn[45016]: Expected Remote Options hash (VER=V4): '0088baee'
Sep 13 10:31:12openvpn[45016]: Local Options hash (VER=V4): 'e05aa1c5'
Sep 13 10:31:12openvpn[45016]: Expected Remote Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 0,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-server'
Sep 13 10:31:12openvpn[45016]: Local Options String: 'V4,dev-type tun,link-mtu 1562,tun-mtu 1500,proto UDPv4,comp-lzo,mtu-dynamic,keydir 1,cipher AES-256-CBC,auth SHA1,keysize 256,tls-auth,key-method 2,tls-client'
Sep 13 10:31:12openvpn[45016]: Fragmentation MTU parms [ L:1562 D:1300 EF:61 EB:135 ET:1 EL:0 AF:3/1 ]
Sep 13 10:31:12openvpn[45016]: Data Channel MTU parms [ L:1562 D:1300 EF:62 EB:135 ET:0 EL:0 AF:3/1 ]
Sep 13 10:31:11openvpn[45016]: Socket Buffers: R=[42080->65536] S=[57344->65536]
Sep 13 10:31:11openvpn[45016]: Control Channel MTU parms [ L:1562 D:166 EF:66 EB:0 ET:0 EL:0 ]
Sep 13 10:31:11openvpn[45016]: LZO compression initialized
Sep 13 10:31:11openvpn[45016]: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 13 10:31:11openvpn[45016]: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Sep 13 10:31:11openvpn[45016]: Control Channel Authentication: using '/var/etc/openvpn/client4.tls-auth' as a OpenVPN static key file
Sep 13 10:31:11openvpn[45016]: Initializing OpenSSL support for engine 'cryptodev'
Sep 13 10:31:11openvpn[45016]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sep 13 10:31:11openvpn[45016]: MANAGEMENT: unix domain socket listening on /var/etc/openvpn/client4.sock
Sep 13 10:31:11openvpn[45016]: OpenVPN 2.3.2 i386-portbld-freebsd8.3 [SSL (OpenSSL)] [LZO] [eurephia] [MH] [IPv6] built on Jul 24 2013
Sep 13 10:31:11openvpn[45016]: 216 variation(s) on previous 5 message(s) suppressed by --mute
Sep 13 10:31:11openvpn[45016]: NOTE: --mute triggered...
Sep 13 10:31:11openvpn[45016]: show_digests = DISABLED
Sep 13 10:31:11openvpn[45016]: show_ciphers = DISABLED
Sep 13 10:31:11openvpn[45016]: mode = 0
Sep 13 10:31:11openvpn[45016]: config = '/var/etc/openvpn/client4.conf'
Sep 13 10:31:11openvpn[45016]: Current Parameter Settings:

Gruesse,
Alberich
 
Hier würde ich mich für meine künftige pfsense Firewall auch dringend für eine Lösung interessieren. Vor allem, weil die Funktionalität ja schon mal gegeben war.

Kommt, das kriegt Ihr hin. Ist doch nur ein Ping... ;)

mfG

Privateer
 
Moin, also ja, so grundsätzlich würde ich das am 10. auch umstellen.
Das Problem ist, so wie ich das sehe geht das nicht mehr seit OpenVPN Version 2.
Siehe: http://http://openvpn.net/index.php...dresses-per-client-when-used-in-tun-mode.html


Zitat:
"In OpenVPN 1.6, when you had to run one OpenVPN instance per client, then it would be more like you expected: a PtP link between the server and each client. In 2.0 however, OpenVPN can handle multiple clients with only one tun interface on the server. To handle this, you can think of the PtP link you see on server as a link between the operating system and OpenVPN. Then when you're inside OpenVPN, another PtP link needs to created to each client. If all O/S would have supported true PtP links over the tun interface, this could have been done with the OpenVPN server using only one IP address and each client using another IP address...."

Und:
"As 192.168.1.5 is only a virtual IP address inside the OpenVPN server, used as an endpoint for routes, OpenVPN doesn't bother to answer pings on this address, while the 192.168.1.1 is a real IP address in the servers O/S, so it will reply to pings."


Ich bin allerdings für Vorschläge offen, also wenn ich da irgendwas übersehen sag bescheid.

Grüße
Lars
 
topology subnet.. das ist neu..sehr cool, danke JackCarver, das hatte ich bis jetzt noch gar nicht entdeckt.
Das hab ich gerade mal auf unserem testserver ausprobiert, scheint mit allen Geräten ganz normal zu funktionieren, ich teste da jetzt noch ein wenig mit rum, aber ich denke dann werde ich das am 10. auf topology subnet umstellen.


Grüße
Lars
 
Hallo an Alle!
Sorry für den "leicht verspäteten" Feedback. Knie-OP, Reha und viel Arbeit auf der Arbeit sind schuld. Na ja, irgendwer oder -was muss immer schuld sein.

Habe nun alles nochmal mit pfsense getestet (2.1.3-RELEASE (i386)) (ja ja ich weiss, es gibt eine neuere Version) und muss/kann sagen, alles funktioniert wieder. Soll folgendes heissen: Meine VPN-clients erhalten jetzt korrekt die *.*.*.1 Addresse als Gateway und die sind auch pingbar. Damit funktioniert das Monitoring der VPN Gateways in der pfsense wieder perfect.

Ich danke allen Beteiligten für die Unterstützung und die gute Lösung.
Viele Grüße
Alberich.
 
Hallo Perfect Privacy Team,
es ist zum Mäusemelken. Bin nun auf pfSense 2.2.2-RELEASE (i386) umgestiegen. Alle VPN-Clients funktionieren. Nur leider das Monitoring der VPN-Gateways geht mal wieder nicht, soll heissen, die *.*.*.1 Adressen sind z.Zt. nicht ping-bar. Kann das einer von Euch bestätigen?

Viele Grüße
Alberich.
 
Ping klappt schon wieder nicht. Ich denke, dass liegt daran, welches Gateway/Subnet ich zugeteilt bekomme:

*************************************************************

PING 10.15.11.1 (10.15.11.1) from 10.15.11.16: 56 data bytes

--- 10.15.11.1 ping statistics ---
1 packets transmitted, 0 packets received, 100.0% packet loss

*************************************************************

PING 10.15.31.1 (10.15.31.1) from 10.15.31.16: 56 data bytes
64 bytes from 10.15.31.1: icmp_seq=0 ttl=64 time=32.049 ms

--- 10.15.31.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.049/32.049/32.049/0.000 ms

*************************************************************

PING 10.15.31.1 (10.15.31.1) from 10.15.31.17: 56 data bytes
64 bytes from 10.15.31.1: icmp_seq=0 ttl=64 time=33.084 ms

--- 10.15.31.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 33.084/33.084/33.084/0.000 ms

*************************************************************

PING 10.12.11.1 (10.12.11.1) from 10.12.11.9: 56 data bytes
64 bytes from 10.12.11.1: icmp_seq=0 ttl=64 time=32.292 ms

--- 10.12.11.1 ping statistics ---
1 packets transmitted, 1 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 32.292/32.292/32.292/0.000 ms

*************************************************************

Zur Zeit bekomme ich für Amsterdam sehr häufig 10.15.11.1 und dieses Gateway ist nicht pingbar !!!
Gibt es evtl. noch mehr Gateways, die nicht pingbar sind? Ob Ihr das vielleicht mal prüfen könntet?

Viele Grüße
Alberich
 
Sicher, daß es nicht bei Dir blockiert wird?
Ich nutze was ähnliches zum Monitoren und habe keine Probleme mit Amsterdam oder anderen Standorten.
Allerdings gab gelegentlich Probleme mit dem Squid-proxy der auf der gateway-adresse, port 3128 horcht. In dem Fall ging dann auch der ping auf die x.x.x.1 schief.
 
Back
Top