OpnSense VIP op PPPOE sessie

[MClaeys]

Naar aanleiding van het sterven van men Fortigate 80D ben ik op OPNsense gesprongen op aanraden van enkele members (tnx Sasuke en Devilkin).

Het is de bedoeling dat er terug iets van hardware voor komt, maar omdat ik nog niet goed weet wat kiezen doe ik het voorlopig op ESX (Heb ik voor handen, dan is alles weer intern bereikbaar dus dan is de WAF weer in orde ).

So far so good, niet echt complex eigenlijk dus intern is alles alweer in orde. Het enige wat ik niet aan de praat krijg is externe toegang.

Ik heb intern een Nginx proxy en een OpenVPN server welke ik extern bereikbaar had via DynDNS.

Bij Fortigate was dit gewoon een VIP maken met source 0.0.0.0, dan een poort en een destination, rule maken en klaar.
Bij OPNsense blijf ik echter tegen de default deny rule vliegen.

Ik heb een VIP gemaakt met IP 0.0.0.0/32 (Interface Proximus, Address 0.0.0.0, geen gateway).
Ik heb een NAT Port "Forward rule" gemaakt. (Interface Proximus, Protocol TCP, geen source (want Any). Destination: VIP, Destination Port Range https, redirect target IP: Nginx, target port https).
Hierop maakt hij zelf een rule aan onder de Proximus interface en die lijkt me eigenlijk wel correct.

De oplossing bijt me waarschijnlijk in de enkels, maar ik kijk er recht over denk ik .

Ik heb ook even getest met het IP van de WAN in de VIP te plaatsen, maar ook dat bracht niet op. Dus daar lijkt het precies niet aan te liggen.

[Sasuke]

Ik zie echt niet in waarom je een VIP moet maken, noch op Fortigate, noch op je OpnSense ?? Een VIP is normaal toch een 'extra' IP op 1 van je interfaces (e.g. als je bijvoorbeeld een routed subnet hebt op je WAN ofzo). Dat dat zo op je FortiGate werkt zal eerder een 'bug' zijn dan dat het de bedoeling was. Daar zou ik bij het FortiBugOS ook niet van verschieten

In jouw geval is het toch gewoon een NAT rule + WAN Firewall rule maken met source (any) (= 0.0.0.0/0) en destination je interne host(s) ?

E.g. (eerste = NAT rule, 2de = WAN rule die de traffiek toelaat.)

2022-02-20 16_10_35-Port Forward _ NAT _ Firewall _ guardian.fusiontek.be.png

2022-02-20 16_11_06-SDWAN _ Rules _ Firewall _ guardian.fusiontek.be.png

[keerekeerweere]

Bij Fortigate was dit gewoon een VIP maken met source 0.0.0.0, dan een poort en een destination, rule maken en klaar.
Bij OPNsense blijf ik echter tegen de default deny rule vliegen.

Ik heb een VIP gemaakt met IP 0.0.0.0/32 (Interface Proximus, Address 0.0.0.0, geen gateway).
Ik heb een NAT Port "Forward rule" gemaakt. (Interface Proximus, Protocol TCP, geen source (want Any). Destination: VIP, Destination Port Range https, redirect target IP: Nginx, target port https).
Hierop maakt hij zelf een rule aan onder de Proximus interface en die lijkt me eigenlijk wel correct.
Ik heb ook even getest met het IP van de WAN in de VIP te plaatsen, maar ook dat bracht niet op. Dus daar lijkt het precies niet aan te liggen.

VIP adres is als ik het goed kan volgen eerder voor multi/redundant WAN setups.
Ik heb gewoon een alias gemaakt "box". (en je kan ook een box6 maken voor ipv6)
vb:

Code: Selecteer alles

Name Type Description Content
box	Host(s)	 example	192.168.1.123

enerzijds de WAN rules de nodige traffic geforward (voor traffic van de opsense machine/vm zelf)

Code: Selecteer alles

Protocol	Source	Port	Destination	Port
IPv4 TCP	*	*	box 	80 (HTTP)

anderzijds de NAT forward rules:

Code: Selecteer alles

nterface	Proto	Address	Ports	Address	Ports	IP	Ports
WAN	TCP	*	*	WAN address	80 (HTTP)	box  	80 (HTTP)

Wist het zelf ook niet meer zo goed... totdat ik dit las:

WAN vs. NAT Port Forward Rule: Which one to use?
Generally speaking, WAN rules should be used for any service running directly on your router and NAT port forward rules for any service host on a server in your internal network (either virtualized or physical). If you run OpenVPN or WireGuard in OPNsense, you will want a WAN rule. If you have a Plex Media Server or Nextcloud on a server in your network and want to open access to the outside world, you will want a NAT Port Forward rule.

[MClaeys]

Ik heb gewoon een alias gemaakt "box". (en je kan ook een box6 maken voor ipv6)

enerzijds de WAN rules de nodige traffic geforward (voor traffic van de opsense machine/vm zelf)

anderzijds de NAT forward rules:

Zo heb ik het nu gedaan, maar ik kom nog steeds op de Default Deny Rule terecht.

Dat dat zo op je FortiGate werkt zal eerder een 'bug' zijn dan dat het de bedoeling was. Daar zou ik bij het FortiBugOS ook niet van verschieten

Misschien heb ik het ooit zo fout aangeleerd, maar zo gebruikte ik het wel. Lijkt me geen bug want dat ging al in elk FortiOS (waar ik mee gewerkt heb, dus 5.4.0 - 6.4.x ofzo, niet zo lang).

Code: Selecteer alles

DNAT, or VIP, is used to map an external IP address to an IP address or address range. The mapping can include all TCP/UDP ports or, if port forwarding is enabled, it only refers to the specific configured ports. As the central NAT table is disabled by default, the term VIP is usually used.

[Splitter]

misschien ook nog een belangrijke: waar maak je de rules ?

priority is een dingetje:
top to bottom, en dan:
floating (quick) => interface groups (quick/non quick) => interface (quick/non quick) => floating (non quick)

als je bv dus een deny hebt in je floating (quick), en dan een allow in je interface, gaat die nooit gematcht worden.

maar je hebt normaal niet meer nodig dan 1 nat rule (en opnsense zou de nodige rule toevoegen in de firewall, bij interface - dus priority blijft wel van toepassing):

interface: wan
version: ipv4
proto: tcp/udp
destination: wan address
destination port range: https
redirect: single host: je nginx host
redirect port: https

je kan overigens ook kiezen op haproxy in opnsense te gebruiken ipv je nginx proxy

[Sasuke]

Plus 1 voor HaProxy. Reverse proxy op je firewall kunnen doen is een supergemak en spaart toch wel wat in beheer van anders een dedicated vm



Je WAN rule is verkeerd. Je moet het verkeer toelaten op je firewall … iet naar je ngninx host. Dus bij je WAN rule kan je gewoon ‘this firewall’ als destination gebruiken. Dan werkt het ook ineens proper van binnenuit en kan je je interne dns (dnsmasq op je firewall?) resolutie naar het firewall lan op sturen. Komt de interne snelheid zeker ten goede.

[MClaeys]

misschien ook nog een belangrijke: waar maak je de rules ?

De deny all staat inderdaad bij de floating rules. Maar in de automatically generated rules, dus ik dacht dat die sowieso onderaan zou staan dan. Ik zie alleszins geen manier om deze te verplaatsen, in tegenstelling tot bijvoorbeeld de rules die je zelf maakt.
Ik maak ze onder Firewall => NAT en Firewall Proximus (alleja, die laatste maakt hij vanzelf nadat ik de rule onder NAT heb aangemaakt).

Van Wan naar LAN heb ik maar 1 rule momenteel, die in de screenshot in men vorige post. Inmiddels een tweede met To Firewall.

je kan overigens ook kiezen op haproxy in opnsense te gebruiken ipv je nginx proxy

Dit is iets wat ik in de toekomst wel wil bekijken, maar deze virtuele setup is maar tijdelijke depanage en om het te leren Dan blijf ik voorlopig liever bij de al werkende Nginx waar ik wel content van ben. Eerst terug naar een bestaande werkende situatie voor ik prul aan iets anders . Daarom dat ik voorlopig ook bij men losse OpenVPN wil blijven.

Je WAN rule is verkeerd. Je moet het verkeer toelaten op je firewall … iet naar je ngninx host. Dus bij je WAN rule kan je gewoon ‘this firewall’ als destination gebruiken. Dan werkt het ook ineens proper van binnenuit en kan je je interne dns (dnsmasq op je firewall?) resolutie naar het firewall lan op sturen. Komt de interne snelheid zeker ten goede.

Heb ik net even getest, maar met een rule naar "This Firewall" krijg ik hetzelfde resultaat. De andere rule was auto-generated via de NAT port forwarding.
Van binnenuit werkt het. Enkel niet extern.

[Sasuke]

Laat Proximus eigenlijk poort 443 toe op thuisverbindignen zonder fixed IP? Of werkte het voordien wel over poort 443

En je bent zeker dat men je default deny rule hit ? Er gebeurd geen NAT aan de wan kant ? Je hebt een public IP op je wan interface ?

Normal zou dit redelijk straightforward moeten zijn. Kan je anders eens de volledige inhoud van je interfaces, firewall rules en Port forward posten. ?

Je hebt toch ook je mgmt poort op iets anders dan 443 gezet ?

[tizzen33]

Laat Proximus eigenlijk poort 443 toe op thuisverbindignen zonder fixed IP? Of werkte het voordien wel over poort 443

Kan aan- of uitgezet worden via MyProximus

[MClaeys]

Proximus laat poort 443 toe op een non-fixed IP, dit is in te stellen op MyProximus. Het komt ook gewoon in de log tevoorschijn .

2022-02-20 19_50_38-Live View _ Log Files _ Firewall _ OPNsense.localdomain.png

En je bent zeker dat men je default deny rule hit ?

Volgens de logs toch, alleja, Live View. Maar ik kan totaal op de foute plaats kijken, nooit eerder met OPNsense gewerkt.

Je hebt een public IP op je wan interface ?

Bij overview staat enkel pppoe/ en een gateway. Gezien ik meteen verkeer blocked zie op WAN als ik via 4G probeer te verbinden lijkt dit alvast wel zo.

Normal zou dit redelijk straightforward moeten zijn.

Dat dacht ik om eerlijk te zijn ook, het is geen nieuw concept voor mij, gewoon een nieuw product toegegeven, kloop wat "wazig" vandaag dus ging ik er vanuit dat ik echt iets overduidelijk over het hoofd zie.

Je hebt toch ook je mgmt poort op iets anders dan 443 gezet ?

Point proven... Normaal het eerste wat ik doe, maar dit keer dus over het hoofd gezien . Het heeft het niet opgelost, maar deze staat nu dus wel degelijk op iets anders.

Interfaces en rules:

[tizzen33]

Ik zou de deny all op IPv4+6 naar het einde verschuiven. In Pfsense gaat het ook van boven naar beneden

[MClaeys]

Het gaat op elke firewall top-down (as far as I know), maar dat zijn auto-generated rules waarvan ik nog niet gevonden heb hoe ik de prio aanpas.

[Sasuke]

Je deny all rules staan bovenaan in je floating rules. Dat kan nooit werken …
Al een chance dat er anti lockout rules aanstaan, anders kon je ook niet aan de gui.

Je gaat die deny all van plaats moeten wijzigen, dat kan normaal door ze aan te klikken en dan naar de rules op de gewenste plaats gaan, daar is dan pijltje met iets zoals ‘move selected rules before this rule’

Maar daar zit wel je probleem, zeer vreemd hoe dat zo is ontstaan.

Hulplijn: https://homenetworkguy.com/how-to/firew ... eat-sheet/

[MClaeys]

Maar die rules kan ik niet aanvinken..., die staan er al van in het begin van de setup. Ik weet dat rules aanvinken kan om ze dan boven een andere te zetten, maar niet met die auto generated rules. Aanklikken ook niet.

[Sasuke]

Hmm … ff bezien dan straks ipv antwoorden uit mijn hoofd op iPad. Ik vermoed dat je ergens een vinken teveel hebt gezet tijdens een of andere setup wizard ofzo.

[MClaeys]

Dat begin ik stilaan ook te vermoeden maar de setup was eigenlijk vrij straight forward. Een interface als WAN aanduiden, 1 als LAN en (indien gewenst) VLAN's definieren en assignen. Dan in de webinterface PPPoE gegevens ingeven en wat rules maken zodat de DMZ machientjes aan internet kunnen, DNS en domotica. Van LAN naar DMZ stond alles default open en daar ben ik zelfs nog niet aan gekomen om dat dicht te zetten.

Men vrouw is morgen grotendeels thuis, dus al iets minder nodig om de camera's remote wat in het oog te houden met de mogelijke storm. Dat scheelt al wat . Misschien begin ik morgen gewoon opnieuw. En ik heb men "backup"-vpn nog op de Fritzbox.

Edit: heb hem af gezet voor vandaag. Morgen eens van nul af aan opnieuw

[Sasuke]

FF nagekeken ... onder floating staat de default deny all inderdaad bovenaan (bij mij onder hoofding 'auto generated rules') .. maar met de optie 'last match' aangevinkt. Dus dat is alvast ok.

Het moet dus toch nog iets anders zijn dan ... kan je die 2 rules met 443 naar de nginx (ipv this firewall) eens disablen ? Want mogelijk hitten die wel, maar werken ze gewoon niet.

[SpecialK]

Op welke poort draait de webinterface van uw firewall? Als die ook op de standaard https poort luistert wint die volgens mij van de port forward.

[devilkin]

Inderdaad, default staat de web interface op 80/443 en die moet je rebinden naar een andere poort.

[MClaeys]

Vandaag met een heldere kop na het werk gewoon de VM gedelete en opnieuw opgezet. Stond snel weer op. Zowat alle rules al hermaakt (en de rest gebeurt wel ad-hod wanneer ik het nodig heb, ik ken de hele rule-set van men vorige firewall niet meer).
Geen idee welk vinkske ik fout heb aangeklikt gisteren waardoor het totaal niet wou werken, maar nu werkt het dus gewoon wel. Het enige dat ik nog niet aan de praat heb is het streamen van men camera beelden via de VPN, maar dat is vermoedelijk nog een poort die ik moet open zetten, en ik kan ze bekijken via Home Assistant dus dat is ook niet zo belangrijk.

Op welke poort draait de webinterface van uw firewall? Als die ook op de standaard https poort luistert wint die volgens mij van de port forward.

Deze stond gisteren inderdaad eerst nog mis, alsook het doorverwijzen van 80 naar 443, maar dat heb ik aangepast en dat heeft het toen niet gefixt. Deze stond wel niet open naar WAN. Maar dat was inderdaad al een domme oversight.

maar met de optie 'last match' aangevinkt.

Ja, dat is me achteraf ook opgevallen. En vandaag bij het opnieuw opzetten stonden al die rules er opnieuw automatisch, dus vrij zeker dat het daar niet aan kan gelegen hebben. Ze konden alleszins niet verplaatst worden.

kan je die 2 rules met 443 naar de nginx (ipv this firewall) eens disablen ? Want mogelijk hitten die wel, maar werken ze gewoon niet.

Die heeft er op een gegeven moment alleen gestaan, zonder resultaat. Het werkt nu overigens volgens die Nginx-rule manier.


Iedereen merci voor het meedenken! Op het VIP gedeelte na was men gedachtengang toch precies correct. Geen idee wat er nu aan de hand was uiteindelijk, maar nu het werkt kan ik er wat verder op gaan prullen en binnenkort eens kijken voor iets van zuinige/krachtige hardware om het om te draaien.

[Splitter]

Op welke poort draait de webinterface van uw firewall? Als die ook op de standaard https poort luistert wint die volgens mij van de port forward.

Deze stond gisteren inderdaad eerst nog mis, alsook het doorverwijzen van 80 naar 443, maar dat heb ik aangepast en dat heeft het toen niet gefixt. Deze stond wel niet open naar WAN.

je kan je wan op 443 forwarden zolang je firewall niet op de wan gaat luisteren.
en een firewall gui wil je meestal effectief niet op de wan laten luisteren

en binnenkort eens kijken voor iets van zuinige/krachtige hardware om het om te draaien.

een apu is daar redelijk handig voor.
of als je met 2 poorten genoeg zou hebben en zelf wat wil bouwen, een systeem met de N3160TN van gigabyte.

[keerekeerweere]

Het enige dat ik nog niet aan de praat heb is het streamen van men camera beelden via de VPN, maar dat is vermoedelijk nog een poort die ik moet open zetten, en ik kan ze bekijken via Home Assistant dus dat is ook niet zo belangrijk.

Als je camera en/of VPN een afzonderlijk subnet of vlan gebruikt die best ook voorzien in de rules...
Natuurlijk ook je VPN nakijken welke subnets je "duwt" naar je client.

Dat was hier nodig om het aan de praat te krijgen. Vermits de VPN een afzonderlijk subnet en de camera's een afzonderlijke VLAN en subnet hebben.

Rules op de IPSec (VPN)

Code: Selecteer alles

Protocol	Source	Port	Destination	Port	Gateway	Schedule	Description 
IPv4 *      *       *       LAN net     *       *       *	
IPv4 *      *       *       camera net  *       *       *	

als je via de VPN ook terug naar buiten wil, ook dezelfde rule met WAN net toevoegen. (je eigen vpn proxy om van externe en buitenlandse locaties aan (geo)restricted sites te kunnen)

[MClaeys]

een firewall gui wil je meestal effectief niet op de wan laten luisteren

Nee inderdaad, default luistert hij wel naar alle interfaces, ik heb niet getest of ik het ook kon openen via de WAN, gewoon enkel op LAN open gezet. Maar de poort had ik initieel niet aangepast.

apu

Tnx, voor de tip!

Als je camera en/of VPN een afzonderlijk subnet of vlan gebruikt die best ook voorzien in de rules...

Die zitten inderdaad in verschillende subnets waar men rules nog niet op orde staan. Ik moet nog eens kijken welke poorten er voor nodig zijn, ik dacht udp9000 maar het is al effe geleden.

[keerekeerweere]

eens kijken voor iets van zuinige/krachtige hardware om het om te draaien

Ik heb dit lang laten draaien op een proxmox met wat containers en VM's. Maar dat was lastig indien je de proxmox moest herstarten na updates.

Ook nog effe op (very low cost) HP T520 thin client via router on a stick configuratie. AMD 1.2Ghz dualcore cpu (afzonderlijke VLAN voor WAN connectie en via switch untagged naar VDSL modem). Ging best wel goed met mijn VDSL snelheden. Enkel als de PPPoe sessie er om één af andere uitlag, sloeg de Unbound naar 100% cpu en begon het systeem te haperen. Met een klein beetje krachtigere hardware geen problemen mee.

Dan toch maar besloten op een afzonderlijke machine die ook weer proxmox doet. Met maar één VM met dubbele netwerk adapter. Deze netwerk adapter is in PCIe passthrough. 10w verbruik met een lenovo desktop i3-7100 en dual intel nic. Proxmox is als het ware een 'poor mans ipmi oplossing' en moet niet tegelijk met de andere proxmox host worden herstart.

[MClaeys]

PPPoE is sowieso wat een zorgenkindje als ik het zo wat lees. Werkt Proximus/Edpnet Fiber nog met PPPoE? Of gebruiken ze daar een andere manier. Gigabit over PPPoE is volgens wat ik lees moeilijk. Niet dat dat nu al aan de orde is maar toch .

[Belgissschenaap]

PPPoE is sowieso wat een zorgenkindje als ik het zo wat lees. Werkt Proximus/Edpnet Fiber nog met PPPoE? Of gebruiken ze daar een andere manier. Gigabit over PPPoE is volgens wat ik lees moeilijk. Niet dat dat nu al aan de orde is maar toch .

Jammergenoeg gebruiken ze nog pppoe.
OK voor nu, maar kan op hogere snelheden vrij belastend worden. Vrij inefficiënte methode.

[tizzen33]

Met de nieuwe Internet Box aka Home Gateway 4 komt er geen pppoe meer aan te pas. Mac adres passthrough is voorzien om een public IP te verkrijgen op een eigen device.