Lokaal de lokale mailserver benaderen

[Paul van der Vlis]

Hallo,

Een klant heeft een lokale mailserver en heeft een ander KPN IP nummer
gekregen.

Eerder kon hij vanuit het lokale netwerk deze server bereiken door de
naam op te geven waaraan het externe IP-nummer staat gekoppeld. Maar nu
werkt dat plots niet meer. Wel van buitenaf dus, maar niet vanaf het
lokale netwerk.

Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?

Groet,
Paul


--
Paul van der Vlis Linux systeembeheer Groningen
https://vandervlis.nl

[Stef]

On 2022-05-09 Paul van der Vlis wrote in xs4all.general:
> Hallo,
>
> Een klant heeft een lokale mailserver en heeft een ander KPN IP nummer
> gekregen.
>
> Eerder kon hij vanuit het lokale netwerk deze server bereiken door de
> naam op te geven waaraan het externe IP-nummer staat gekoppeld. Maar nu
> werkt dat plots niet meer. Wel van buitenaf dus, maar niet vanaf het
> lokale netwerk.
>
> Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?

Dat is wel gek. Hier heb ik een vergelijkbare situatie, maar dan met
een webserver en dat werkt na omzetten van het IP als voorheen. Is wel
een oude Fritz 7360v2 (dus wel IPv6 ;-) ). Is er geen lokale DNS die nog
het oude IP teruggeeft of een cache in de mail client o.i.d.?


--
Stef

UH-OH!! I put on "GREAT HEAD-ON TRAIN COLLISIONS of the 50's" by
mistake!!!

[Paul van der Vlis]

Op 09-05-2022 om 14:54 schreef Stef:

> On 2022-05-09 Paul van der Vlis wrote in xs4all.general:
>> Hallo,
>>
>> Een klant heeft een lokale mailserver en heeft een ander KPN IP nummer
>> gekregen.
>>
>> Eerder kon hij vanuit het lokale netwerk deze server bereiken door de
>> naam op te geven waaraan het externe IP-nummer staat gekoppeld. Maar nu
>> werkt dat plots niet meer. Wel van buitenaf dus, maar niet vanaf het
>> lokale netwerk.
>>
>> Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?
>
> Dat is wel gek. Hier heb ik een vergelijkbare situatie, maar dan met
> een webserver en dat werkt na omzetten van het IP als voorheen. Is wel
> een oude Fritz 7360v2 (dus wel IPv6 ;-) ). Is er geen lokale DNS die nog
> het oude IP teruggeeft of een cache in de mail client o.i.d.?

Er is daar een lokale DNS, maar dat is weer een ander netwerk.
Daar gaat alles goed.

Er zijn er echter ook wat wifi-apparaten die direct aan de Fritzbox
hangen. Over dat netwerk heb ik het. Daar is geen lokale DNS anders dan
de Fritzbox. Alle apparaten daar hebben dit probleem.

De TTL had ik flink kort gemaakt, dus hij zou niet mogen cachen. Maar
wellicht goed een van die apparaten eens opnieuw te starten.

[richard lucassen]

On Mon, 9 May 2022 14:27:51 +0200
Paul van der Vlis <pa...@vandervlis.nl> wrote:

> Een klant heeft een lokale mailserver en heeft een ander KPN IP
> nummer gekregen.
>
> Eerder kon hij vanuit het lokale netwerk deze server bereiken door de
> naam op te geven waaraan het externe IP-nummer staat gekoppeld. Maar
> nu werkt dat plots niet meer. Wel van buitenaf dus, maar niet vanaf
> het lokale netwerk.
>
> Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?

Er is ergens (dacht ik) een instelling om RFC1918 netwerken of in ieder
geval het bekende 192.168.178.0/24 te kunnen laten resolven met een
externe DNS. Ik meen me te herinneren dat dat per domein gaat.

Tethering via mobiele telefoons hebben dat ook. Wat je kunt overwegen
is de DoT op quad9.org als DNS in te stellen, want het zou best kunnen
zijn dat udp/53 verkeer wordt afgevangen door de router.

Probeer anders eerst even 9.9.9.9 en 149.112.112.112 als DNS in te
stellen.

--
richard lucassen
http://contact.xaq.nl/

[richard lucassen]

On Mon, 9 May 2022 15:39:16 +0200
richard lucassen <mailin...@lucassen.org> wrote:

> > Een klant heeft een lokale mailserver en heeft een ander KPN IP
> > nummer gekregen.
> >
> > Eerder kon hij vanuit het lokale netwerk deze server bereiken door
> > de naam op te geven waaraan het externe IP-nummer staat gekoppeld.
> > Maar nu werkt dat plots niet meer. Wel van buitenaf dus, maar niet
> > vanaf het lokale netwerk.
> >
> > Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?
>
> Er is ergens (dacht ik) een instelling om RFC1918 netwerken of in
> ieder geval het bekende 192.168.178.0/24 te kunnen laten resolven met
> een externe DNS. Ik meen me te herinneren dat dat per domein gaat.
>
> Tethering via mobiele telefoons hebben dat ook. Wat je kunt overwegen
> is de DoT op quad9.org als DNS in te stellen, want het zou best kunnen
> zijn dat udp/53 verkeer wordt afgevangen door de router.
>
> Probeer anders eerst even 9.9.9.9 en 149.112.112.112 als DNS in te
> stellen.

Ik heb die vraag ook wel eens gesteld in een van de xs4all
nieuwsgroepen en Miquel van Smoorenburg heeft toen precies verteld waar
het stond.

[Paul Slootman]

Was het niet dat de Fritz weigert hostname te resolven die naar het
lokale netwerk of naar het externe IP adres verwijzen? Dan moet je de
domeinnaam ergens invullen. Het heet DNS rebind protection, te vinden
onder home network -> network settings en dan onderin.
heet...


Paul

[Rob]

Dat probleem is niet relevant als je DNS naam verwijst naar een IP
adres wat je eigen publieke adres is toch? En als de domeinnaam niet
veranderd is zou die setting ook OK moeten zijn.

Waar het hier om gaat is zgn "hairpin NAT" dwz dat als je vanaf het
LAN een connectie maakt naar je eigen publieke IP dat dan de destination
NAT rules ("port forwarding") worden uitgevoerd en het verkeer ge-NAT
wordt terug naar je eigen netwerk. Ik dacht dat een Fritzbox dat zelf
al doet want daar kun je op dat gebied niks configureren. Andere
routers die "een configuratieschil rondom een Linux box" zijn hebben
bij destination NAT rules mogelijk ook het publieke IP adres als
match criterium en dat moet dan worden aangepast. Misschien dat
de Fritzbox dat intern wel heeft, en dat ie gereboot moet worden ofzo?

[Roger]

On 2022/05/09 14:27, Paul van der Vlis wrote:
> Hallo,
>
> Een klant heeft een lokale mailserver en heeft een ander KPN IP nummer gekregen.
>
> Eerder kon hij vanuit het lokale netwerk deze server bereiken door de naam op te geven
> waaraan het externe IP-nummer staat gekoppeld. Maar nu werkt dat plots niet meer.  Wel van
> buitenaf dus, maar niet vanaf het lokale netwerk.

Je bedoelt dat de server zowel buiten als binnen bv. mail.example.com heet? Ik heb
wel eens gelezen dat zoiets werkte met een FRITZ!Box, maar dat kan eigenlijk alleen
als de FB bij port forwarding ook U-bocht connecties kan maken. Zoiets lijkt mij
eerder een bug dan een feature.

De enige goede oplossing is m.i. split DNS met een interne DNS server en deze door
DHCP laten configureren op hosts in het lokale netwerk. Dat draait hier al jaren op
een Linux servertje.

> Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?

Ik zou niet weten welke.

Groeten,
-Roger

[Roger]

Je bedoelt denk ik DNS Rebind Protection. Dat vind je onder "Home Network ->
Network -> Network Settings" als je onderaan "Additional Settings" aanklikt.
Maar ik zie even niet hoe dat met het onderhavige probleem te maken zou
kunnen hebben.

Groeten,
-Roger

[Roger]

On 2022/05/09 16:31, Roger wrote:
> Je bedoelt dat de server zowel buiten als binnen bv. mail.example.com heet? Ik heb
> wel eens gelezen dat zoiets werkte met een FRITZ!Box, maar dat kan eigenlijk alleen
> als de FB bij port forwarding ook U-bocht connecties kan maken. Zoiets lijkt mij
> eerder een bug dan een feature.

Toch maar eens even getest (n.a.v. de reactie van Rob). Het werkt inderdaad out of
the box. Kennelijk hangt de NAT-regel van een port forward niet aan een specifieke
interface. Niet mijn idee.

Groeten,
-Roger

[richard lucassen]

On Mon, 9 May 2022 16:31:30 +0200
Roger <nosuc...@example.com> wrote:

> > Ik heb die vraag ook wel eens gesteld in een van de xs4all
> > nieuwsgroepen en Miquel van Smoorenburg heeft toen precies verteld
> > waar het stond.
>
> Je bedoelt denk ik DNS Rebind Protection. Dat vind je onder "Home
> Network -> Network -> Network Settings" als je onderaan "Additional
> Settings" aanklikt. Maar ik zie even niet hoe dat met het onderhavige
> probleem te maken zou kunnen hebben.

Bij herlezen van de vraag zie ik het: hij gaat naar het externe nummer.
Het is dus geen intern DNS issue.

R.

[richard lucassen]

On Mon, 9 May 2022 16:53:16 +0200
Roger <nosuc...@example.com> wrote:

> Toch maar eens even getest (n.a.v. de reactie van Rob). Het werkt
> inderdaad out of the box. Kennelijk hangt de NAT-regel van een port
> forward niet aan een specifieke interface. Niet mijn idee.

Dat kan nou juist erg handig zijn voor dit soort dingen, behalve als de
server op het eigen netwerk zit uiteraard. Dan is een split horizon
de enige nette oplossing lijkt me

[Roger]

On 2022/05/09 17:14, richard lucassen wrote:
> On Mon, 9 May 2022 16:53:16 +0200
> Roger <nosuc...@example.com> wrote:
>
>> Toch maar eens even getest (n.a.v. de reactie van Rob). Het werkt
>> inderdaad out of the box. Kennelijk hangt de NAT-regel van een port
>> forward niet aan een specifieke interface. Niet mijn idee.
>
> Dat kan nou juist erg handig zijn voor dit soort dingen, behalve als de
> server op het eigen netwerk zit uiteraard.

Hairpin NAT doe je toch juist als de server op het eigen netwerk zit? (en
je geen zin hebt om split DNS op te tuigen) Maar ik ben bang dat het in de
meeste gevallen juist onbewust wordt gedaan, met alle gevolgen van dien.

> Dan is een split horizon
> de enige nette oplossing lijkt me

Wat mij betreft altijd. Maar nette oplossingen kosten tijd en geld. En die
krijg je niet altijd (maar weer wel om je rot te zoeken naar de oorzaak van
een 'plotseling probleem' dat feitelijk een disaster-waiting-to-happen was).

Groeten,
-Roger

[Paul van der Vlis]

Op 09-05-2022 om 14:27 schreef Paul van der Vlis:

> Hallo,
>
> Een klant heeft een lokale mailserver en heeft een ander KPN IP nummer
> gekregen.
>
> Eerder kon hij vanuit het lokale netwerk deze server bereiken door de
> naam op te geven waaraan het externe IP-nummer staat gekoppeld. Maar nu
> werkt dat plots niet meer.  Wel van buitenaf dus, maar niet vanaf het
> lokale netwerk.
>
> Zie ik wellicht een instelling in de Fritzbox over het hoofd o.i.d.?

Klant had wat apparaten opnieuw opgestart, maar het hielp niet.

Later functioneerde alles opeens. Onduidelijk waarom.

[Paul van der Vlis]

Op 09-05-2022 om 16:53 schreef Roger:

Ik doe dat juist steeds vaker op Linux firewalls. Eerder deed ik
port-forwarding ook specifiek op een bepaald interface, maar in de
praktijk blijkt het wel erg handig om dat algemeen te doen. Dan werkt de
port-forwarding van binnenuit ook, en ook verkeer wat via een VPN
binnenkomt bijvoorbeeld. Of via een noodverbinding.

Wellicht heeft het ook nadelen, maar heb ik nog niet gezien. Een
port-forwarding is immers ook juist om iets open te zetten, en als het
al richting internet open staat lijkt het me niet zo erg als het ook nog
tegenover andere interfaces openstaat. Toch?

Bijvoorbeeld zoiets:
---------
ports="80,443"

iptables -A FORWARD -d 192.168.208.23 -p tcp \
--match multiport --dport $ports -j ACCEPT

iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp \
--match multiport --dport $ports -j DNAT --to 192.168.208.23
----------

Die 1.2.3.4 is dan je externe IP adres.

[Rob]

Paul van der Vlis <pa...@vandervlis.nl> wrote:

> Bijvoorbeeld zoiets:
> ---------
> ports="80,443"
>
> iptables -A FORWARD -d 192.168.208.23 -p tcp \
> --match multiport --dport $ports -j ACCEPT
>
> iptables -t nat -A PREROUTING -d 1.2.3.4 -p tcp \
> --match multiport --dport $ports -j DNAT --to 192.168.208.23
> ----------
>
> Die 1.2.3.4 is dan je externe IP adres.

Ja maar dan bak je dus je externe IP adres in je rule!
M.a.w. dat gaat mis als je externe IP adres verandert.
Dat was precies wat hier beschreven werd als een probleem.

[richard lucassen]

On Mon, 9 May 2022 18:04:23 +0200

Paul van der Vlis <pa...@vandervlis.nl> wrote:

> > Toch maar eens even getest (n.a.v. de reactie van Rob). Het werkt
> > inderdaad out of
> > the box. Kennelijk hangt de NAT-regel van een port forward niet aan
> > een specifieke interface. Niet mijn idee.
>
> Ik doe dat juist steeds vaker op Linux firewalls. Eerder deed ik
> port-forwarding ook specifiek op een bepaald interface, maar in de
> praktijk blijkt het wel erg handig om dat algemeen te doen. Dan werkt
> de port-forwarding van binnenuit ook, en ook verkeer wat via een VPN
> binnenkomt bijvoorbeeld. Of via een noodverbinding.
>
> Wellicht heeft het ook nadelen, maar heb ik nog niet gezien. Een
> port-forwarding is immers ook juist om iets open te zetten, en als
> het al richting internet open staat lijkt het me niet zo erg als het
> ook nog tegenover andere interfaces openstaat. Toch?

Zet die server in z'n eentje in een DMZ netwerk, dan kun je altijd NAT
naar het externe ip toepassen, ook als je van binnen komt. Wel zo
netjes en je hebt geen split horizon DNS nodig. Op de server zelf kun
je de hosts file gebruiken eventueel.

Een server die van buitenaf bereikbaar is hoort sowieso *altijd* in een
afgesloten en zoveel mogelijk dichtgetimnmerde DMZ te staan!

[Roger]

Dat is maar één van de mogelijke problemen. Omdat het in deze situatie
werkt zonder interne DNS server voor interne IP-adressen, gebruik je de
facto een externe DNS server voor interne communicatie. Dat werkt, dus
geen probleem. Toch?

Maar als je internetverbinding er een hele tijd uit ligt (dat gebeurt
in Nederland gelukkig zelden), dan valt opeens ook een stuk interne
communicatie uit elkaar. En niemand snapt waarom. Ook moet je voor elke
poort die je wilt benaderen een forward rule aanmaken (of het lokale
IP-adres gebruiken, dat kan altijd).

En dan komt uiteraard het moment waarop de router wordt vervangen door
een exemplaar dat deze handige functie niet heeft...

Groeten,
-Roger

[Paul van der Vlis]

Op 09-05-2022 om 18:31 schreef Rob:

Ja, dat is inderdaad een nadeel. En het kan niet goed zonder.

[Paul van der Vlis]

Op 09-05-2022 om 19:39 schreef Roger:

> On 2022/05/09 18:31, Rob wrote:
>> Paul van der Vlis <pa...@vandervlis.nl> wrote:
>>> Bijvoorbeeld zoiets:
>>> ---------
>>> ports="80,443"
>>>
>>> iptables -A FORWARD -d 192.168.208.23 -p tcp \
>>>     --match multiport --dport $ports -j ACCEPT
>>>
>>> iptables -t nat -A PREROUTING  -d 1.2.3.4  -p tcp \
>>>     --match multiport --dport $ports -j DNAT --to 192.168.208.23
>>> ----------
>>>
>>> Die 1.2.3.4 is dan je externe IP adres.
>>
>> Ja maar dan bak je dus je externe IP adres in je rule!
>> M.a.w. dat gaat mis als je externe IP adres verandert.
>> Dat was precies wat hier beschreven werd als een probleem.
>
> Dat is maar één van de mogelijke problemen. Omdat het in deze situatie
> werkt zonder interne DNS server voor interne IP-adressen, gebruik je de
> facto een externe DNS server voor interne communicatie. Dat werkt, dus
> geen probleem. Toch?
>
> Maar als je internetverbinding er een hele tijd uit ligt (dat gebeurt
> in Nederland gelukkig zelden), dan valt opeens ook een stuk interne
> communicatie uit elkaar.

Ja, daar heb je een punt.

> En niemand snapt waarom. Ook moet je voor elke > poort die je wilt benaderen een forward rule aanmaken

Als hij van buiten bereikbaar moest zijn, dan had je dat al.

> (of het lokale IP-adres gebruiken, dat kan altijd).
>
> En dan komt uiteraard het moment waarop de router wordt vervangen door
> een exemplaar dat deze handige functie niet heeft...

Groeten,

[Paul van der Vlis]

Op 09-05-2022 om 18:54 schreef richard lucassen:

Wellicht heb je gelijk aan bovenstaande, en is het ook zo op te lossen.

Groeten,

[richard lucassen]

On Mon, 9 May 2022 22:23:32 +0200
Paul van der Vlis <pa...@vandervlis.nl> wrote:

> > Zet die server in z'n eentje in een DMZ netwerk, dan kun je altijd
> > NAT naar het externe ip toepassen, ook als je van binnen komt. Wel
> > zo netjes en je hebt geen split horizon DNS nodig. Op de server
> > zelf kun je de hosts file gebruiken eventueel.
> >
> > Een server die van buitenaf bereikbaar is hoort sowieso *altijd* in
> > een afgesloten en zoveel mogelijk dichtgetimnmerde DMZ te staan!
>
> Wellicht heb je gelijk aan bovenstaande, en is het ook zo op te
> lossen.

Beschouw de server altijd als een server met een voor jou onbekende,
Chinees, Russisch, Koreaans, Braziliaans, of wat dies meer zij,
sprekende administrator die van alles wil uitvreten. In een DMZ kun je
ervoor zorgen dat-ie weinig kan (en zeker niet naar het interne
netwerk) en dan is de lol er gauw vanaf.

[Roger]

Helemaal mee eens uit oogpunt van veiligheid. Maar een DMZ lost het onderhavige
probleem niet op.

Want welke IP-adressen ga je gebruiken in die DMZ? Voor IPv6 is er geen probleem
(publieke adresruimte te over), maar voor IPv4 heb je de keuze tussen een publiek
subnet (kost extra geld, als je het al kunt krijgen) en RFC1918 adressen. In het
laatste geval heb je nog steeds het adresseringsprobleem dat hier uitgebreid is
besproken.

Verder ondersteunt de FRITZ!Box geen DMZ. Je zult dan een andere router moeten
gaan gebruiken (die dan misschien weer geen hairpin NAT doet).

Groeten,
-Roger

[Paul van der Vlis]

Op 10-05-2022 om 09:45 schreef Roger:

Je kunt ook het enige externe IPv4 adres gebruiken wat je hebt, lijkt
me. Gewoon port-forwarding naar een afgesloten netwerkje.

> Verder ondersteunt de FRITZ!Box geen DMZ. Je zult dan een andere router
> moeten
> gaan gebruiken (die dan misschien weer geen hairpin NAT doet).

Ik gebruik graag Linux als firewall, dat doet dat wel.

[Roger]

On 2022/05/10 10:09, Paul van der Vlis wrote:
> Op 10-05-2022 om 09:45 schreef Roger:

>> Helemaal mee eens uit oogpunt van veiligheid. Maar een DMZ lost het onderhavige
>> probleem niet op.
>>
>> Want welke IP-adressen ga je gebruiken in die DMZ? Voor IPv6 is er geen probleem
>> (publieke adresruimte te over), maar voor IPv4 heb je de keuze tussen een publiek
>> subnet (kost extra geld, als je het al kunt krijgen) en RFC1918 adressen. In het
>> laatste geval heb je nog steeds het adresseringsprobleem dat hier uitgebreid is
>> besproken.
>
> Je kunt ook het enige externe IPv4 adres gebruiken wat je hebt, lijkt me.

Dat wordt geconsumeerd door het PPPoE endpoint op je router.

> Gewoon port-forwarding naar een afgesloten netwerkje.

En wat gebruik je in dat afgesloten netwerkje? Weer RFC1918 adressen?

>> Verder ondersteunt de FRITZ!Box geen DMZ. Je zult dan een andere router moeten
>> gaan gebruiken (die dan misschien weer geen hairpin NAT doet).
>
> Ik gebruik graag Linux als firewall, dat doet dat wel.

Met een DMZ heb je geen hairpin NAT meer nodig. Twee haakse bochten volstaan ;)

Maar goed, een DMZ is niet de oplossing van het probleem dat je hier neerlegde.
DMZ of geen DMZ is een vraag die daar los van staat.

Groeten,
-Roger

[richard lucassen]

On Tue, 10 May 2022 11:05:19 +0200
Roger <nosuc...@example.com> wrote:

> > Je kunt ook het enige externe IPv4 adres gebruiken wat je hebt,
> > lijkt me.
>
> Dat wordt geconsumeerd door het PPPoE endpoint op je router.
>
> > Gewoon port-forwarding naar een afgesloten netwerkje.
>
> En wat gebruik je in dat afgesloten netwerkje? Weer RFC1918 adressen?

Tuurlijk, gewoon minimaal een /30 en er zijn zat RFC1918 adressen. NAT
ervoor en gaan met die banaan. Als het een mailserver is hoeft alleen
maar 25/tcp naar buiten open te staan en de rest kan (op een paar admin
rules na) gewoon op slot.

> > Ik gebruik graag Linux als firewall, dat doet dat wel.
>
> Met een DMZ heb je geen hairpin NAT meer nodig. Twee haakse bochten
> volstaan ;)

En het is netjes gerouteerd zonder rare fratsen.

[Rob]

richard lucassen <mailin...@lucassen.org> wrote:
> On Tue, 10 May 2022 11:05:19 +0200
> Roger <nosuc...@example.com> wrote:
>
>> > Je kunt ook het enige externe IPv4 adres gebruiken wat je hebt,
>> > lijkt me.
>>
>> Dat wordt geconsumeerd door het PPPoE endpoint op je router.
>>
>> > Gewoon port-forwarding naar een afgesloten netwerkje.
>>
>> En wat gebruik je in dat afgesloten netwerkje? Weer RFC1918 adressen?
>
> Tuurlijk, gewoon minimaal een /30 en er zijn zat RFC1918 adressen. NAT
> ervoor en gaan met die banaan. Als het een mailserver is hoeft alleen
> maar 25/tcp naar buiten open te staan en de rest kan (op een paar admin
> rules na) gewoon op slot.

Ik vind dat altijd wat raar, RFC1918 adressen gebruiken in een DMZ netwerk.
Maar het is kennelijk standaard in veel omgevingen.
Een publiek /29 netwerkje (zoals je bij XS4ALL kon krijgen) ligt meer
voor de hand.

>> > Ik gebruik graag Linux als firewall, dat doet dat wel.
>>
>> Met een DMZ heb je geen hairpin NAT meer nodig. Twee haakse bochten
>> volstaan ;)
>
> En het is netjes gerouteerd zonder rare fratsen.

De fratsen zijn niet veel anders dan met hairpin NAT, je moet nog steeds
ofwel NAT doen ofwel split-DNS.

[richard lucassen]

On Tue, 10 May 2022 13:21:17 +0200
Rob <nom...@example.com> wrote:

> > Tuurlijk, gewoon minimaal een /30 en er zijn zat RFC1918 adressen.
> > NAT ervoor en gaan met die banaan. Als het een mailserver is hoeft
> > alleen maar 25/tcp naar buiten open te staan en de rest kan (op een
> > paar admin rules na) gewoon op slot.
>
> Ik vind dat altijd wat raar, RFC1918 adressen gebruiken in een DMZ
> netwerk. Maar het is kennelijk standaard in veel omgevingen.
> Een publiek /29 netwerkje (zoals je bij XS4ALL kon krijgen) ligt meer
> voor de hand.

Ik zie daar geen echt voordeel in. Tegenwoordig zijn de ipv4 adressen
schaars en kun je een enkelvoudig ip gebruiken om een webserver in
DMZ1 te draaien en een mailserver in DMZ2 met de diverse poorten naar
de diverse DMZ's geNAT

> > En het is netjes gerouteerd zonder rare fratsen.
>
> De fratsen zijn niet veel anders dan met hairpin NAT, je moet nog
> steeds ofwel NAT doen ofwel split-DNS.

Tsja, waren we maar eerder met ipv6 begonnen dan was dit helemaal geen
issue geweest. Het blijft toch typisch ipv4 gedoe. I.t.t. een aantal
jaren terug werkt ipv6 nu echt wel goed. Maar zolang er nog ISP's zijn
die glas aanbieden zonder ipv6 (T-Mobile heb ik begrepen) dan schiet
het niet op. Het moest maar eens wettelijk vastgelegd gaan worden.

R.