[sslh] OpenvpnAS traffic wordt herkend als ssl

[NiRo]

Hallo iedereen

Ik wil mijn OpenVPN access server toegankelijk maken op poort 443. Ik gebruik de software op een Proxmox LXC container. De sslh daemon is als volgt ingesteld:

DAEMON_OPTS="--user sslh --listen 192.168.0.201:443 --openvpn 192.168.0.201:1194 --ssl 192.168.0.204:443 --pidfile /var/run/sslh/sslh.pid --timeout 5"

Als ik een verzoek stuur naar poort 1194 werkt de verbinding perfect, maar als ik via sslh werk wordt openvpn doorgestuurd naar de ssl server (info uit journalctl), wat uiteraard een error geeft. Ik heb sslh nu op standalone mode staan maar ook via de inetd service werkt dit niet.

Is er iets fout aan mijn configuratie of is het sslh die het pakket niet goed herkent?

Alvast bedankt!
Rob Nickmans

[Room42]

Interessant, deze kende ik nog niet!

Wat zie je in de logging voorbij komen? Ik zie dat ie naar syslog logt maar je kunt hem ook in de voorgrond draaien met '--foreground' en dan verbose loggen met '--verbose'.

En je hebt het over inetd. Welk OS draai je?

Ik ben benieuwd!

[ Voor 9% gewijzigd door Room42 op 04-03-2020 19:25 ]

[NiRo]

Ik heb via de client op mijn gsm 2x verbinding proberen te maken (192.168.0.121) met als uitkomst 'Connection error'.

Ik draai Debian 10 als LXC op Proxmox. (Ja, tunneling en nesting zijn geactiveerd in de config).

Bedankt voor de reactie!

Dit is de log:

root@ap:~# sslh --foreground --verbose --user sslh --listen 192.168.0.201:443 --openvpn 127.0.0.1:1194 --ssl 192.168.0.204:443 --pidfile /var/run/sslh/sslh.pid --timeout 5
openvpn addr: localhost:openvpn. libwrap service: (null) log_level: 1 family 2 2 []
ssl addr: 192.168.0.204:https. libwrap service: (null) log_level: 1 family 2 2 []
listening on:
ap.**DOMEIN**:https []
timeout: 5
on-timeout: openvpn
listening to 1 addresses
turning into sslh
sslh-fork 1.18-1 started
capabilities: =
accepted fd 4
**** writing deferred on fd -1
probing for openvpn
probing for ssl
connecting to 192.168.0.204:https family 2 len 16
ssl:connection from 192.168.0.121:37206 to ap.**DOMEIN**:https forwarded from ap.**DOMEIN**:55736 to 192.168.0.204:https
flushing deferred data to fd 3
server socket closed
connection closed down
accepted fd 4
**** writing deferred on fd -1
probing for openvpn
probing for ssl
connecting to 192.168.0.204:https family 2 len 16
ssl:connection from 192.168.0.121:37208 to ap.**DOMEIN**:https forwarded from ap.**DOMEIN**:55738 to 192.168.0.204:https
flushing deferred data to fd 3
server socket closed
connection closed down

(192.168.0.201 is het ip van de LXC, 192.168.0.204 is het ip van mijn nginx reverse proxy)

[ Voor 3% gewijzigd door NiRo op 04-03-2020 19:40 ]

[Room42]

@NiRo Ik ben dus niet bekend met sslh maar wat als je de --ssl nu eens weglaat? Route ie dan wel direct naar OpenVPN?

En heb je ook al eens een andere OpenVPN-client geprobeerd?

[ Voor 20% gewijzigd door Room42 op 05-03-2020 02:00 ]

[LanTao]

Volgens de documentatie werkt 127.0.0.1 niet als destination.

[NiRo]

@Room42 Ik heb nu de --ssl optie weggelaten en sslh werkt nu perfect, zelfs over mijn domein.

Ik heb vorige keer ook al geprobeerd via de interne Windows client maar ook dat werkte toen niet. Openvpn is niet ingebouwd in Windows, en de software van Openvpn geeft een NETWORK_SEND_ERROR. Hij verbind maar disconnect dan weer meteen. Ook wordt dit verkeer niet gelogd in sslh dus mogelijk zit de fout in de client zelf?

Het hing dus aan de ssl optie maar dat betekent ook dat ik nu zonder webverkeer zit. Dat verkeer stuurt hij nu allemaal door naar Openvpn.

@LanTao Inderdaad, daar heb ik over gelezen. Ook dat is in orde en aangepast in de startpost.

[ Voor 16% gewijzigd door NiRo op 05-03-2020 17:29 ]

[XiMMiX]

Met sslh kan ik je niet helpen. Eerste keer dat ik er van hoor, wel interessant als het zou werken.

Maar als workaround zou je kunnen kijken naar de port-share optie van OpenVPN. Dan heb je geen proxy zoals sslh nodig, maar stuurt OpenVPN zelf inkomende connecties die geen openvpn protocol spreken door.

[NiRo]

@XiMMiX Ik heb de portsharing optie eens geprobeerd (wat al een hele opgave is met een OpenvpnAS server) maar ik vraag me af of de openvpn server dan in dezelfde container moet zitten. Momenteel zijn beiden namelijk gescheiden. Hier las ik dat je via de sacli tool makkelijk je instellingen kan updaten maar LOCAL_IP is nogal dubbelzinnig.

Moet ik deze twee servers dus in 1 container laten draaien? En is LOCAL_IP dan gewoon localhost? Of 0.0.0.0 of zoiets dergelijk?

[ Voor 5% gewijzigd door NiRo op 05-03-2020 18:16 ]

[XiMMiX]

Sorry, niet opgevallen dat je access server gebruikte. Heb ik helaas geen ervaring mee. Dus ik ga maar even af op wat de link die je gaf zegt.

"Configure a custom redirection – only works with IP addresses on the server itself, nothing external". Lijkt me duidelijk, je HTTPS server moet in dezelfde machine/container draaien. Inderdaad localhost/127.0.0.1 of een ander IP als het maar een IP van de server zelf is. 0.0.0.0 is geen echt IP adres, dus werkt niet.
Ze geven wel een oplossing:
"And technically, if you really wanted to for some reason, you can make service forwarding to an external address possible by using iptables to redirect a port on a local interface to an external system."
Maar dan wordt het allemaal wel erg geknutsel.

Wel vreemd, de man page van openvpn zelf meldt niets over een beperking tot alleen IPs op de server zelf. Ik heb het zelf nooit anders gebruikt dan met 127.0.0.1, dus het kan dat die beperking voor openvpn zelf geldt.

[RudolfR]

Ik heb een vergelijkbare setup in OpenWRT.

sslh v18.06.7

/usr/sbin/sslh -p<lokaal_ip_router> 443 --ssh <lokaal_ip_ssh_ap> YYYY --ssl <lokaal_ip_nginx_proxy> 443 --openvpn <lokaal_ip_openvpn_server> XXXX -t 5 -v --user nobody --pidfile /var/run/sslh.pid

lokaal_ip_ssh_ap en lokaal_ip_openvpn_server zijn hetzelfde; ook op OpenWRT, maar een andere dan lokaal_ip_router.

[ Voor 5% gewijzigd door RudolfR op 06-03-2020 09:38 ]

[NiRo]

Hallo allen

In de hele Corona-crisis heb ik weer wat tijd gevonden om verder te werken aan dit project. Ik heb inmiddels de portshare succesvol ingesteld en ik kan 1 url bereiken over zijn domeinnaam. De andere locatie, die van mijn Nextcloud opslag is echter nog niet operatief.

De Apache server op mijn Nextcloud instance geeft een 'Bad request' error met als reden dat ik SSL probeer te verkrijgen over http. Dit is echter niet het geval. Als tab icon krijg ik dat van Openvpn. SSL certificaten zijn juist en operatief, en het verkeer wordt ook correct doorgesluisd door nginx, mijn reverse proxy. Het heeft immers de hele tijd zo gewerkt.

Als iemand iets heeft aan specifieke config files kan ik deze nog altijd bijvoegen. Ik vraag me af wat ik nog moet aanpassen zodat dit werkzaam is.

Noot: ik laat openvpn luisteren op 443, wat ik doorstuur naar 4433. Ik stuur het verkeer van de ene URL naar een lokaalip:8006 (Proxmox) en dat van Nextcloud naar lokaalip:443. Ik heb ook al geprobeerd om de SSL certificaten op Nextcloud te zetten die ik momenteel alleen had op mijn reverse proxy maar ook dat werkt niet.

Alvast bedankt!
Rob Nickmans
-------------------
UPDATE:
Ik heb de default-ssl uitgeschakeld in Apache op de Nextcloud instance. Nu werkt het externe verkeer wel, maar het interne weer niet meer. Uiteraard, want 443 verbindingen worden nergens naartoe gestuurd. Heeft iemand een oplossing zodat ze allebei blijven werken? (Ik prefereer namelijk om via het lokaal ip te browsen als ik thuis ben, om de eenvoudige reden dat alles dan veel sneller verloopt en ik niet met NAT hairpinning etc zit.)

Nogmaals bedankt!
-------------------
UPDATE:
Ik heb gevonden dat de reverse proxy alle verkeer over http doorstuurde. Vandaar dus de error van Apache. Bij deze werkt alles zoals het hoort. Bedankt iedereen voor alle tips en hulp!

[ Voor 6% gewijzigd door NiRo op 18-03-2020 12:06 ]