Ik heb een probleem bij een klant waar ik niet uit kom. Ik heb om vertrouwelijke redenen van de klant de IP-adressen iets aangepast.
De klant heeft een MS Windows 2003-netwerk. Er zijn elf servers, waarvan twee domain controllers en een SurfControl-appliance met ISA Server 2006.
De SurfControl-appliance staat in het netwerk (10.88.10.0/24) met alleen de LAN-NIC (10.88.10.251) aangesloten. Deze NIC (10.88.10.251 is de default gateway voor alle clients, servers en andere randapparatuur. Er zijn twee gateways, 10.88.10.1 (netwerk gemeente Amsterdam met primary access naar internet) en 10.88.10.21 (eigen DMZ met secundary access naar internet). 10.88.10.21 is een Cisco PIX die de scheiding vormt tussen het interne netwerk en de DMZ. De routes staan benoemd op de SurfControl-appliance. Al het verkeer via ISA wordt toegestaan, omdat deze geen firewall-functie als zodanig heeft. Er wordt gebruik gemaakt van persistant routes op de SurfControl-appliance naar DMZ, te weten de netwerken 10.88.11.0/24, 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 en 192.168.254.0/24. De SurfControl-appliance is in de AD opgenomen en is member server.
De client krijgt via DHCP de volgende zaken toegewezen, naast het standaard IP-adres: DNS (10.88.10.33, 10.88.10.34 en default gateway (10.88.10.251).
Er wordt gebruik gemaakt van de proxy binnen ISA. Deze geldt alleen voor HTTP en HTTPS. I.v.m. FTP-functionaliteit en de manier waarop ISA hiermee omgaat is dit buiten de proxy gehouden en wordt dit direct door ISA afgehandeld. Daarnaast staat SurfControl aan om het surfgedrag passief te monitoren overeenkomstig het huisreglement.
Wat is mijn probleem? Verkeer wat geïnitieerd wordt vanaf het interne netwerk (10.88.10.0/24) kan altijd naar de DMZ of naar buiten toe. Verkeer vanaf de DMZ gaat dood. Nu is dit op te lossen door op bijvoorbeeld iedere interne server de route naar de Cisco PIX (10.88.10.21) toe te voegen. Dit wordt door de klant niet gewenst. De SurfControl-appliance is de vervanger van een Linux firewall. Deze stond op adres 10.88.10.19. Het routeren ging daar wel twee kanten goed op. Er wordt dus, volgens mijn logica, iets geblokkeerd door ISA. Ik weet het alleen niet. Wat is de oplossing?
De klant heeft een MS Windows 2003-netwerk. Er zijn elf servers, waarvan twee domain controllers en een SurfControl-appliance met ISA Server 2006.
De SurfControl-appliance staat in het netwerk (10.88.10.0/24) met alleen de LAN-NIC (10.88.10.251) aangesloten. Deze NIC (10.88.10.251 is de default gateway voor alle clients, servers en andere randapparatuur. Er zijn twee gateways, 10.88.10.1 (netwerk gemeente Amsterdam met primary access naar internet) en 10.88.10.21 (eigen DMZ met secundary access naar internet). 10.88.10.21 is een Cisco PIX die de scheiding vormt tussen het interne netwerk en de DMZ. De routes staan benoemd op de SurfControl-appliance. Al het verkeer via ISA wordt toegestaan, omdat deze geen firewall-functie als zodanig heeft. Er wordt gebruik gemaakt van persistant routes op de SurfControl-appliance naar DMZ, te weten de netwerken 10.88.11.0/24, 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24 en 192.168.254.0/24. De SurfControl-appliance is in de AD opgenomen en is member server.
De client krijgt via DHCP de volgende zaken toegewezen, naast het standaard IP-adres: DNS (10.88.10.33, 10.88.10.34 en default gateway (10.88.10.251).
Er wordt gebruik gemaakt van de proxy binnen ISA. Deze geldt alleen voor HTTP en HTTPS. I.v.m. FTP-functionaliteit en de manier waarop ISA hiermee omgaat is dit buiten de proxy gehouden en wordt dit direct door ISA afgehandeld. Daarnaast staat SurfControl aan om het surfgedrag passief te monitoren overeenkomstig het huisreglement.
Wat is mijn probleem? Verkeer wat geïnitieerd wordt vanaf het interne netwerk (10.88.10.0/24) kan altijd naar de DMZ of naar buiten toe. Verkeer vanaf de DMZ gaat dood. Nu is dit op te lossen door op bijvoorbeeld iedere interne server de route naar de Cisco PIX (10.88.10.21) toe te voegen. Dit wordt door de klant niet gewenst. De SurfControl-appliance is de vervanger van een Linux firewall. Deze stond op adres 10.88.10.19. Het routeren ging daar wel twee kanten goed op. Er wordt dus, volgens mijn logica, iets geblokkeerd door ISA. Ik weet het alleen niet. Wat is de oplossing?
/u/34216/avatar-60x60.png?f=community){kind=avatar}