Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Subnet di fastweb

    Scheduled Pinned Locked Moved Italiano
    5 Posts 2 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      proto
      last edited by

      Ciao a tutti,
      avrei bisogno di un consiglio e qualche delucidazione.

      Sto configurando un subnet /29 per l'ufficio con un router fastweb.

      La mia idea è la seguente:

      • 1 IP per il traffico LAN
      • 4 IP per la DMZ

      Per il momento pfsense gira su host ESXi 6, senza problemi apparenti.
      Ho configurato le NIC dell'host e configurato vSwitch e portgroup in modo da avere:

      [WANs]  – nic fisica

      • WAN0
      • WAN1
      • WANx

      [DMZs] – no nic, rete interna all'host ESXi

      • DMZ1
          -DMZx

      [LANs] – nic fisica

      • LAN0

      Dove: [XXXs] è il vSwitch e quanto è in lista sono i portgroup.

      La "coppia" WAN0 - LAN0 fornisce il traffico ai client della LAN ed eventualmente posso fare PortForward verso alcuni server temporanei di test.

      La coppia WAN1 - DMZ1 mi fornisce il Bridge (chiamiamolo BR1). Sul ESXi i portgroup sono impostati in mod. promiscua e sulle NIC del firewall non ho impostato alcun indirizzo IP, BR1 compreso in modo da assegnare l'IP al device in DMZ.
      In questo modo dovrei ottenere un FW trasparente e impostando i tunables relativi al bridge, posso fare il filtering direttamente sull'IF BR1:

      net.link.bridge.pfil_member    0
      net.link.bridge.pfil_bridge        1

      A questo punto dovrei avere un DMZ reale, per quanto virtualizzata.

      E' sicura una configurazione del genere?

      grazie.

      1 Reply Last reply Reply Quote 0
      • P
        Pakken
        last edited by

        Forse non ho ben capito quali sono le tue esigenze… ma leggendo al volo non era molto più semplice creare una subnet separata per la dmz, bloccare tutti gli accessi da dmz ->lan e nattare 1:1 ip_pubblico:ip_privato ?

        Avresti ugualmente avuto una dmz funzionante senza troppe rotture di scatole.

        Ciao :)
        Luca

        1 Reply Last reply Reply Quote 0
        • P
          proto
          last edited by

          In realtà la mia esigenza è proprio quella di evitare il NAT per le DMZ e isolare le macchine pubbliche.

          1 Reply Last reply Reply Quote 0
          • P
            Pakken
            last edited by

            Curiosità mia… cosa ti turba del NAT? Le macchine pubbliche le potevi isolare anche creando un'altra subnet privata, chiaro che non vai a fare nat 1:1 su ip della lan.

            1 Reply Last reply Reply Quote 0
            • P
              proto
              last edited by

              @Pakken:

              Curiosità mia… cosa ti turba del NAT? Le macchine pubbliche le potevi isolare anche creando un'altra subnet privata, chiaro che non vai a fare nat 1:1 su ip della lan.

              In realtà nulla, non posso fare a meno del NAT! Ma ho trovato più "semplice" la soluzione trasparente per quelle macchine che devono rimanere isolate e intendo che non devono assolutamente generare traffico/aprire connessioni verso la LAN (produzione).

              Con NAT 1:1 mi tocca creare VIP, NAT, REGOLE.
              Con BR, set di regole sull'IF del Bridge. Poi a valle del BR ci può essere un solo host o addirittura un altro FW (a questo punto il nat non è più un'opinione, ma credo quasi una certezza).

              Il turbamento è solo questo: mischiare NAT e bridge sullo stesso fw sarà una m.*ata?

              Magari è solo una mia paranoia di fine anno, per cui fino al prossimo non ci penso.
              Buon finale!

              1 Reply Last reply Reply Quote 0
              • First post
                Last post
              Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.