Linux Router+Firewall+DMZ met meerdere public IP's probleem

[Verwijderd]

Hallo,

Ik zit met het volgende probleem. We hebben een Debian Linux (Lenny 5.04) server staan met 2 NIC's.
Deze is ingericht voor Firewall/Router/DMZ met onze glasvezel verbinding.
Op deze server is verder ook een caching DNS opgezet voor de servers in DMZ.

Probleem is dat ik in de DMZ achter deze Firewall/Router meerdere servers met publieke IP's heb
staan welke voor internet bereikbaar moeten zijn. (oa. webserver,ftp server)

Voor de duidelijkheid even een kleine schets van de situatie.
(tekening zegt meestal meer dan 1000 woorden ... toch?)
Ik heb even fictieve IPs gebruikt (1.1.1.x), maar dit zijn dus eigenlijk publieke IP's.

code:

          Glasvezel-switch
                 |
                 |
                eth1 (1.1.1.2=extern ip vanaf internet voor LAN)
                 |
        Linux Router/Firewall DMZ
                 |
                eth0 (1.1.1.124=gw)
                 |                     eth2+---------------------+eth0         +-----+
                 |-------------------------|Linux Router/firewall|-------------| LAN |
                 |                  1.1.1.3+---------------------+ 10.0.0.0/8  +-----+
                 |
     ----------|DMZ|----------
    |            |            |
    |            |            |
server-1     server-2      server-3
public IP    public IP     public IP
 1.1.1.4      1.1.1.5       1.1.1.6

Alle LAN gebruikers moeten via iptables SNAT rule geNAT worden naar 1.1.1.2.
En de DMZ servers moeten met hun eigen publieke IP vanaf buiten bereikbaar zijn.

Probleem is dat het wel lukt om middels iptables SNAT rule al het verkeer vd. DMZ servers
naar buiten te krijgen maar vanaf buiten zijn deze DMZ servers te zien met het 1.1.1.2 adres.
Maar we willen juist dat deze DMZ servers met hun eigen publieke IP naar buiten gaan en ook
op hun eigen IP vanaf buiten te bereiken zijn.

We hebben een range van 1.1.1.0 - 1.1.1.127 gekregen van onze Glasvezel aanbieder.
Gateway = 1.1.1.1


Op de "Linux Router/Firewall DMZ" server zijn de volgende settings voor de NIC's ingesteld:

eth1:
address 1.1.1.2
netmask 255.255.255.252
gateway 1.1.1.1

eth0:
address 1.1.1.124
netmask 255.255.255.128
<geen gateway ingesteld>


En settings op bv. server-1 in de DMZ (Windows XP testlaptop)
IP : 1.1.1.4
netmask : 255.255.255.128
Gateway : 1.1.1.124
DNS : 1.1.1.124


De SNAT rule die uiteindelijk werkt voor al het verkeer vd. DMZ server naar buiten te krijgen is:

$IPTABLES -t nat -A POSTROUTING -o eth1 -s 1.1.1.0/25 -j SNAT --to-source 1.1.1.2

Dit is prima voor al het verkeer vanaf de LAN, maar niet voor de DMZ servers.
Deze moeten dus via hun eigen IP van/naar internet bereikbaar zijn.

Ik vermoed dat er dus bij de eth1 kant op de "Linux Router/Firewall DMZ" op 1 of andere manier 'geluisterd'
moet kunnen worden naar de gehele IP range (1.1.1.0/25) maar heb geen idee hoe dit voor elkaar te krijgen.
IP forwarding staat ook al ingesteld op de Linux router (cat /proc/sys/net/ipv4/ip_forwarding = 1)


Ik hoop dat iemand hier een goede suggestie voor heeft of kan aangeven wat ik eventueel over het hoofd zie.

Alvast bedankt.

[Belgar]

Het is al laat, dus misschien ben ik niet meer helder, maar waarom wil je nog een keer natten op je dmz? je kunt toch 1.1.1.3 gebruiken als publiek adres van je LAN?

Indien dit niet de bedoeling is, waarom NAT je het hele subnet dat je hebt? al het verkeer dat geNAT moet worden komt van 1.1.1.3. Ik ken de andere entries in de table niet, maar dit op zichzelf zorgt er volgens mij voor dat de servers vanaf buiten niet meer bereikbaar zijn.

[Verwijderd]

Toch nog even reageren dan voordat ik mijn bedje induik

Het is al laat, dus misschien ben ik niet meer helder, maar waarom wil je nog een keer natten op je dmz? je kunt toch 1.1.1.3 gebruiken als publiek adres van je LAN?

Vanwege de 2e en final check door de firewall naar buiten toe. De 1e firewall direct op het LAN aangesloten staat strakker ingesteld (=meer rules) voor een 1e strengere check wat wel niet naar binnen/buiten LAN mag.
Daarna wordt verkeer welke niet uit DMZ komt (dus vanaf LAN) uiteindelijk via 1 public IP naar buiten moeten en daar hebben we dus 1.1.1.2 voor gekozen.

Indien dit niet de bedoeling is, waarom NAT je het hele subnet dat je hebt? al het verkeer dat geNAT moet worden komt van 1.1.1.3. Ik ken de andere entries in de table niet, maar dit op zichzelf zorgt er volgens mij voor dat de servers vanaf buiten niet meer bereikbaar zijn.

Als ik die SNAT regel niet toevoeg dan werkt het helemaal niet. Ik krijg dan geen internet verkeer van/naar de testlaptops (1.1.1.4 en 1.1.1.5).
Ik zie vast iets over het hoofd maar kom er gewoon ff niet meer uit

Bij onze huidige situatie (nu nog met een ADSL router/modem ipv. de Glasvezel-switch) hadden we dit eerst ook maar toen konden we het oplossen dmv. een static route toe te voegen op de ADSL modem/router welke al het 1.1.1.0 subnet verkeer door routerde naar IP vd. buitenkant vd. firewall (in dit vb. dus naar 1.1.1.2)

Omdat we daar nu een switch hebben staan ipv. modem/router werkt het blijkbaar net ff anders (kan natuurlijk geen static route instellen op de switch) ... alleen kom ik er ff niet uit hoe dit op te lossen ?

[Belgar]

Ik bedoelde meer: waarom haal je de het gehele subnet door NAT (-s 1.1.1.0/25).

Daar je slechts 1 IP uit je tweede linux box krijgt is dit overkill, als je nu je NAT tabel bekijkt zul je waarschijnlijk het volgende zien:

X1 out, 1.1.1.3 port y1
X2 out, 1.1.1.3 port y2
X3 out, 1.1.1.3 port y3

etc.

Volgens mij wil je het volgende (bijv):

inkomend:
dest 1.1.1.4:80 pass
dest 1.1.1.5:80 pass
dest 1.1.1.6:80 pass
dest 1.1.1.2 static nat 1.1.1.3
drop all

uitgaand:
source 1.1.1.3 static nat 1.1.1.2

Als ik die SNAT regel niet toevoeg dan werkt het helemaal niet. Ik krijg dan geen internet verkeer van/naar de testlaptops (1.1.1.4 en 1.1.1.5).

Laat je traffic met andere destinations als 1.1.1.2 wel specifiek door? Als je filtert op alleen tables gaat je firewall per definitie geen verkeer doorlaten geadresseerd aan iets anders dan 1.1.1.2

[ Voor 27% gewijzigd door Belgar op 21-06-2010 09:41 ]

[Verwijderd]

Hi,

Oplossing gevonden door de router/firewall te veranderen in een bridging firewall.

Op deze manier kan ik dus gewoon de publieke IP's in de DMZ gebruiken en ook de DMZ beschermen middels onze iptables firewall rules die we al hadden (met hier en daar wat kleine aanpassingen).

Blij dat het nu werkt in onze testopstelling, dan kunnen we nu (eindelijk) verder !