PfSense, 2nd wan IP

[StarWing]

Ik heb een vraagstuk waar ik niet helemaal uitkom, en ik probeer hiervoor de meest nette oplossing voor te vinden.

Setup:
ESXi doos, met 3 vlans, (WAN, LAN, IOT) waarop draait: (enkel de relevante machines)
-pfSense, dit de 3 interfaces routeert over mijn netwerk.
-Ubuntu machine, dewelke ik gebruik om vanop andere plaatsen te SSH'en naar mijn interne netwerk. Luistert op poort 443
Waarom poort 443 ? Omdat deze meestal op andere netwerken naar buitenaf openstaat en ik dus meestal zeker ben dat ik kan verbinden met mijn thuisnetwerk
-Ubuntu machine waarop JellyFin draait.
Deze jellyfin luistert op https poort 80 (wegens het niet meer beschikbaar zijn van poort 443)

De pfSense is ingesteld dat deze poort 443 (NAT) forward naar de SSH doos.
Tevens draait er op de pfSense een HA proxy dewelke de inkomende jellyfin requests forward naar de jellyfin server.
Bereikbaar via https://jellyfin.mijndomein.be:80

Probleem:
Recente firewalls met DPI gaan soms de jellyfin blokkeren omdat deze HTTPS verkeer over poort 80 gaat sturen. Resultaat is dat ik niet kan verbinden op mijn jellyfin.
Ideaal luistert deze op poort 443, maar daar draait de SSH server reeds op.

Volgens mij kan ik de HAproxy niet instellen dat ik zowel de SSH als de jellyfin kan routeren op poort 443 ?

Wat zou een mogelijke oplossing kunnen zijn om zowel de SSH als de jellyfin op poort 443 te laten luisteren ? Ik had gedacht om op de pfSense een 2de wan IP te laten nemen, en daar dan de HA proxy op te laten luisteren, maar ik vind dit zonde van het extra IP, plus dan ga ik mogelijks in de problemen komen met mijn ACME/letsencrypt certificaat

Iemand een goed idee ?

[Tomsworld]

Tip onderzoek dit eens :

SSLH – A SSL/SSH MULTIPLEXER


https://www.rutschle.net/tech/sslh/README.html

https://github.com/yrutschle/sslh

https://ostechnix.com/sslh-share-port-https-ssh/


Ik weet dat xs4all.nl dat gebruikte.

Zelf nog niet genoeg tijd in kunnen steken.

[Joebar]

Kan met haproxy/acme. Je creëert 2 backends en dan via een acl laat je beslissen dewelke moet gebruikt worden. If host = a.mijndomein.be -> backend 1. If host = b.mijndomein.be -> backend 2.

[silentkiller]

@Joebar: dat werkt volgens mij enkel voor HTTP(S) verkeer omdat die host normaal uit de HTTP header gehaald wordt

[Sasuke]

Is het dan misschien niet beter om een http applet voor SSH access te gebruiken? Elke degelijke firewall gaat ssh traffiek op een andere poort er ook sowieso uithalen, dus heb je in principe geen oplossing. Eventueel Ubuntu cockpit gebruiken of iets dergelijks ?

Of moet/wil je tunnelen ? Maar dan heb je die http poort ook niet nodig toch ?

[CCatalyst]

-Ubuntu machine, dewelke ik gebruik om vanop andere plaatsen te SSH'en naar mijn interne netwerk. Luistert op poort 443
Waarom poort 443 ? Omdat deze meestal op andere netwerken naar buitenaf openstaat en ik dus meestal zeker ben dat ik kan verbinden met mijn thuisnetwerk

Ok, maar er zijn nog poorten die doorgaans wel te bereiken zijn: 2082, 3306, 4430, 6667, 8080, 8888. Onder 1024 nog heel wat meer.

Heb je dan ook geen probleem met DPI firewalls bij SSH over 443? Het is vrij triviaal om het verschil te zien met HTTPS bij de handshake.

Is dit effectief een specifiek probleem met locaties waar echt wel enkel 80/443 te bereiken zijn, of is dit slechts hypothetisch? Of is de achterliggende bedoeling eigenlijk om dit verkeer bewust niet te laten opvallen door het op 443 te sturen?

Ik zou iets proberen met port knocking (enfin, een variant daarvan). Default is het jellyfin op 443, maar na de port knocking is het voor een bepaalde tijd SSH.

Als je niet beperkt wordt tot een bepaalde DNS server kan je ook SSH over DNS op poort 53 toepassen.

Anders met een tunnel.

[Joebar]

@Joebar: dat werkt volgens mij enkel voor HTTP(S) verkeer omdat die host normaal uit de HTTP header gehaald wordt

hmm, good point. Ik gebruik deze setup wel om wss en rpc connecties te sturen en daar werkt het prima.

[conehead]

Hallo,

Misschien niet naar wat je op zoek bent maar kijk eens naar cloudflare argo routing ... Hadden een abo dat gratis is tot 50 gebuikers en argo routing zit in dat pakket. Of naar iets als tailscale...

[bogon]

Ik zou ofwel een VPN gebruiken, ofwel een "poor man's VPN": SSH forwarding. Het gemakkelijkste is een SOCKS proxy maken.
Bv.

Code: Selecteer alles

ssh -p 443 -D 1337 mijn.server.org

Stel dan je browser in (kan in Firefox of met Hotplate SOCKS proxy plugin op Chromium-based browsers) om localhost:1337 als proxy te gebruiken. Alle traffic via je browser gaat dan via je SSH-connectie. Let wel: in Chrome-based browsers kan dat enkel met DNS, niet met IP-adressen. Als je SOCKS proxy aan staat kan je dan verbinden met je Jellyfin zoals in je lokale netwerk (bv. gewoon browsen naar https://jellyfin.mijn.home)

[StarWing]

socks proxy gebruik ik reeds op de SSH (onder andere).
Ik routeer er ook een RDP over naar 2 W10 esxi guests.

Probleem is:
1/ vanop onze vakantie locatie is enkel 443/80 open naar buiten toe (kan ik niet veranderen)
2/ vanop mijn werk idem. Enkel 443/80 open naar buiten. (met DPI) en SSH werkt via een omweg
Maar ik wil dat (jellyfin) dus ook op mijn GSM, en daar is die omweg net iets te omslachtig.

De jellyfin wordt vooral gebruikt door de zoon (met autisme) vanop het internaat. Ik kan hem geen meerdere handelingen laten doen. Hij moet kunnen op jellyfin klikken en dat moet werken

Mooiste oplossing zou zijn via de HA proxy:
ssh.mijndomein.be
en
jellyfin.mijndomein.be
maar dat krijg ik dus niet in gang. Althans het SSH hoofdstuk niet.

[Belgissschenaap]

Jouw situatie zou dit wel kunnen gebruiken:

https://freeloadbalancer.com/

Daar behandelen ze exact wat jij wilt. Wel 2 nadelen

• Bandbreedte over de load balancer is max 20mbps

• Die youtuber is echt irritant om naar te luisteren, maar vond niet meteen een geschreven versie

[CCatalyst]

Heb nog steeds moeite met het probleem te zien:

1. Moet Jellyfin - wat is dat, een media library oid? - per se op https zitten? Is HTTP poort 80 niet goed (met unieke paswoorden en beperking van de IP's die toegang krijgen weliswaar)? Ik verkies persoonlijk ook alles op TLS, maar in dit geval voor wat video streaming is plain-text HTTP misschien nog opportuun. Netflix is ook pas recent overgeschakeld naar TLS voor de streams. Of is het - zoals ik al eerder vroeg - ook de bedoeling om dit allemaal te verbergen van werkgever/school/etc?

2. Kan men vanuit het internaat niet op andere poorten dan 80/443? Ik denk iig ook niet dat er daar een DPI firewall staat.

[Belgissschenaap]

Heb nog steeds moeite met het probleem te zien:

1. Moet Jellyfin - wat is dat,

Jellyfin is zoals plex, maar dan open source en gratis