41078
netweters
|
17661
gesprekken
|
19082
vragen
|
Hallo,
Ik heb thuis een palo alto firewall achter mijn modem staan die door bridging ook een publiek ip adres krijgt.
De laatste tijd heb ik ondervonden dat mijn publiek ip adres soms verandert. Op zich is dat geen probleem omdat ik via een script het ip van mijn domeinnaam verander naar het nieuw ip adres.
Het probleem is echter dat de default gateway ook verandert. Ik heb hiervoor een default route met als next hop de default gateway. Als deze verandert, werkt deze route niet meer.
Op de firewall kan je ook een fqdn meegeven als next hop. Ik heb dus een nslookup gedaan naar de default route en krijg dus effectief ook een hostname (........ .access.telenet.be).
Mijn vraag is nu of deze hostname hetzelfde blijft als het ip van de default gateway verandert, heeft iemand hier ervaring mee?
Zoniet, heeft iemand een idee hoe ik dit best aanpak? Ik heb nu gewoon een policy rule dat als de next hop onbereikbaar is, dat de firewall een andere interface gebruikt om het internet te bereiken (gewoon als een client die rechtstreeks verbonden is met de modem). Nadeel hiervan is dat mijn VPN's dan niet opnieuw up komen.
Alvast bedankt!
Opgelost! Ga naar oplossing.
Normaal gezien moet jij toch geen default gateway instellen op de WAN zijde. Die wordt automatisch toegekend aan uw router. Want dat IP adres is dynamisch. Als je dan in uw router dan een DDNS provider instelt die ook eigen domeinnamen ondersteunt heb je er toch geen omijken naar. En aan de LAN zijde blijft de default gateway toch altijd hetzelfde naargelang je het ingeseld hebt. Meestal het 2e of het voorlaatste adres in de range 192.168.X.X. Dus 192.168.X.1 of 192.168.X.254 want 192.168.X.0 is het netwerk en 192.168.X.255 is het broadcastadres. Uiteraard bij een /24 netwerk.
Je hoeft geen statische default route te configureren.
Ga naar de configuratie van je externe interface --> IPv4 tab --> check de box bij "Automatically create default route pointing to default gateway provided by server"
Zie screenshot van mijn firewall.
Palo Alto heeft ook een DDNS client aan boord, zodat je geen externe machine nodig hebt om een script te draaien. Ik gebruik DuckDNS als DNS provider. Deze is gratis en wordt native ondersteund door Palo Alto.
BTW: ik ben Palo Alto Networks certified trainer. Google maar eens "palo alto networks courses steven eerdekens" 😉
Bedankt voor je antwoord Steven!
Ik had na mijn post wat research gedaan en deze optie ook gevonden en ik zag dat dit aan lag.
Het probleem is echter dat ik werk met een 'dual isp' setup met twee externe interfaces (1 voor bridging en andere gewoon als telenet client met ip 192.168.0.2).
Ik heb een PBF rule zodat hij failovert als de next hop van mijn publiek interface (bridging) onbereikbaar is.
Zal straks eens de statische route verwijderen en zien of mn setup nog altijd werkt.
Het probleem is wel dat als de next hop verandert van telenet, dat dit waarschijnlijk niet meteen failovert maar pas als als er een dhcp renew wordt uitgevoerd? Zou jij dit weten?
Want als het toch instant wordt aangepast in de routetabel, dan is die pbf niet nodig.
Die palo DDNS zal ik ook eens opzoeken, wist dat niet. Merci! (Cloudflare is blijkbaar wel niet supported)
Ik zie dat je idd Palo Alto en F5 certificaten hebt. Zijn ook twee vendors waar ik ongeveer 8 maanden mee werk 😄
Ikzelf heb vorig jaar mn PCNSA gedaan en onlangs geslaagd voor PSE.
Zo zie je maar dat er nog veel valt te leren over Palo Alto.
Nogmaals bedankt voor je berichtje!
@fmoghimi schreef:Ik had na mijn post wat research gedaan en deze optie ook gevonden en ik zag dat dit aan lag.
Het probleem is echter dat ik werk met een 'dual isp' setup met twee externe interfaces (1 voor bridging en andere gewoon als telenet client met ip 192.168.0.2).
Ik heb een PBF rule zodat hij failovert als de next hop van mijn publiek interface (bridging) onbereikbaar is.
Zal straks eens de statische route verwijderen en zien of mn setup nog altijd werkt.
Het probleem is wel dat als de next hop verandert van telenet, dat dit waarschijnlijk niet meteen failovert maar pas als als er een dhcp renew wordt uitgevoerd? Zou jij dit weten?
Want als het toch instant wordt aangepast in de routetabel, dan is die pbf niet nodig.
PBF is inderdaad niet nodig (vroeger wel, maar tegenwoordig is er een betere oplossing):
2 statische routes met verschillende metrics, waarvan de primaire route gekoppeld is aan een "path monitoring" profiel, waarbij je bijv Google DNS 8.8.8.8 monitort. Als die onbereikbaar wordt, verdwijnt de primaire route uit de routing tabel en wordt de backup route actief.
https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA10g000000PLL8CAO
Probleem is wel dat dit enkel mogelijk is voor manuele routes die je zelf configureert.
Niet voor een default route die je aanvaardt van je ISP.
Je kan wel de path monitoring achterwege laten en enkel een backup route toevoegen met een hogere metric (50 bijv) naar 192.168.0.1. Dan zal dan enkel werken als je primaire externe interface down gaat.
Maar ik denk dat dit voldoende moet zijn, want ook de backup route gaat via dezelfde ISP, wat niet ideaal is 😉
Ik zou dus voor de oplossing hierboven gaan, zonder de path monitoring dus. Zo doe ik het ook.
PS: een FQDN als next hop is geen oplossing. Dit wordt gebruikt bij bedrijven met verschillende sites die een uniforme firewall config willen, en waarbij het next hop IP geresolved wordt via hun interne DNS server.
@fmoghimi schreef:Ik zie dat je idd Palo Alto en F5 certificaten hebt. Zijn ook twee vendors waar ik ongeveer 8 maanden mee werk 😄
Ikzelf heb vorig jaar mn PCNSA gedaan en onlangs geslaagd voor PSE.
Zo zie je maar dat er nog veel valt te leren over Palo Alto.
Nice. Ik moet als trainer altijd om de 2 jaar de hoogste certificaten renewen.
Maar 't is ondertussen allemaal parate kennis. Enkel de nieuwigheden, maar die komen ook terug in de cursussen die ik geef. 😉
Heb gisterenavond mn setup aangepast naar wat jij zei idd.
Gewoon twee statische routes met verschillende metrics en path monitoring op primary route.
Lijkt mij het beste.
Nogmaals bedankt voor de hulp!
Ok, maar nu heb je dus geen dynamische next hop he, voor als je een nieuw IP adres (en potentiëel ook een nieuwe default gateway) krijgt.
De kans dat dit gebeurt lijkt me groter dan dat je primaire route zou uitvallen en je kan overfalen op een tweede route, die dan via dezelfde modem en provider loopt ...
Zo'n setup doe je doorgaans als je twee ISP's gebruikt met verschillende apparatuur en backbone.
De "redundante" setup die je nu gecreëerd hebt, zal niet echt redundant zijn.
De mijne ook niet, maar toch kies ik persoonlijk voor deze oplossing, zonder path monitoring, omdat je je dan niet moet bekommeren over eventuele IP/Default gateway changes.