pfSense utgående NAT: les de genererte reglene først

Åpne Firewall, deretter NAT, deretter Outbound, og les modusen før du legger til noe. I Automatic-modus genererer pfSense regler for WAN-grensesnittene og, blant dem, for fjern tilgang VPN-nettverk, så puljen du er i ferd med å legge til er ofte allerede dekket. En manglende håndskrevet rad er ikke bevis for at oversettelsen mangler. Rekkefølgen nedenfor hindrer deg i å bytte hele brannmuren til Manual for å løse én pulje.

Modusen avgjør hvem som vedlikeholder oversettelsen for hvert annet nettverk på boksen, og det er en større beslutning enn ett VPN-unntak.

Automatic-modus dekker allerede VPN-puljen

Hver modus har sin egen eier. Automatic genererer regler for WAN-grensesnittene og inkluderer fjern tilgang VPN-nettverk blant kildene sine. Hybrid beholder de genererte reglene og lar deg legge til manuelle ved siden av. Manual slutter å generere noe, så hver oversettelse på brannmuren blir ditt ansvar, også de du ikke skrev. En fjerde innstilling deaktiverer utgående NAT helt. En rad som ser håndskrevet ut beviser ingenting før du vet hvilken modus som er aktiv.

I Automatic og Hybrid viser siden også de genererte reglene. Les dem før du konkluderer med at en VPN-pulje ikke har noen oversettelse: se etter puljens nettverk i kildekolonnen og WAN-grensesnittet i grensesnittkolonnen.

Velg Hybrid bare for et gjennomgått unntak

Et dokumentert unntak er fortsatt mulig når utgangspolicyen virkelig er annerledes. Tenk deg en server som deler ut 10.90.0.0/24, der brannmuren skal gi IPv4-internetutgang og rutingen allerede velger WAN. Den forventede transformasjonen er at kilden 10.90.0.23 skrives om til WAN-adressen. Sjekk om en generert regel allerede gjør dette på den utgangen; hvis ikke, bevarer Hybrid den automatiske dekningen og legger til din gjennomgåtte regel.

Bruk den faktiske VPN-puljen som kilde, eller et støttet alias for den, og velg aldri en urelatert adresse bare fordi navnet på OpenVPN-instansen mangler i en velger. Unngå en kilde any, som også oversetter trafikk brannmuren selv skaper.

Ikke flytt hele brannmuren til Manual for én pulje. Den beslutningen omfordeler vedlikeholdet for hvert interne nettverk og hver fremtidig WAN-endring.

NAT velger ikke utgangen

Rutingen velger utgangsgrensesnittet; en utgående NAT-regel beskriver bare hvordan kilden skrives om når en pakke forlater systemet. En tilordning for WAN tvinger ikke en pakke som rutingen sendte et annet sted til å gå via WAN, og derfor kan ikke NAT legge til rette for en feil rute. Inspiser også gjeldende 1:1 NAT-oppføringer og unntak, siden rekkefølgen betyr noe og en ny rad ikke nødvendigvis vinner. Og utgående-siden er ikke filter-siden.

En oversatt kilde er ikke tillatelse til å nå enhver destinasjon. Klientene trenger fortsatt en rute gjennom tunnelen og en brannmurregel som slipper trafikken deres inn, og den valgte utgangen trenger en fungerende returvei. Hold LAN-only tilgang atskilt fra tillatelse til internettutgang.

Bevis transformasjonen på en ny tilkobling

Etter en godkjent endring, test med en ny autorisert tilkobling i stedet for å gjenbruke en eksisterende, fordi etablerte tilstander beholder sin tidligere transformasjon. Bekreft kildeadressen som faktisk forlater WAN, og at svaret kommer tilbake gjennom samme tilstand. Ikke tøm hele tilstandstabellen som første steg; det skjuler hvilken regel som endret resultatet. Noter modusen, regelen, puljen og utgangen i endringssaken.

Dette eksempelet dekker bare IPv4-utgang. Det sier ingenting om en IPv6-transformasjon eller filtreringspolicy, og et design som trenger en, må oppgi det separat. Den ferdige registreringen lister den tillatte klienttrafikken, grensesnittet som bærer den, og grunnen til at kilden i det hele tatt må skrives om.