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

    Timeout RDP

    Scheduled Pinned Locked Moved Français
    8 Posts 2 Posters 4.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.
    • R
      ritek
      last edited by

      Bonjour,

      J'ai du mal à identifier mes problémes de déconnexion RDP .(PC comme mac)

      Livebox PRo(172.16.3.1)–(172.16.3.2)pfsense--lan(192.168.0.1/22)
      J'ai laissé la configuration(rules etc) par defaut.

      TSE installé sur 192.168.0.219

      toutes les ips en 192.16.0.1/24 n'ont pas de probléme de timeout.
      toutes les ips 192.168.1.* 192.168.2.* ont des pbs de timeout.

      Si je désactive pf(devient un simple routeur) je n'ai plus de probléme.
      Je ne vois pas trop ce que pfsense joue dans tt ca car le traffic ne devrait pas passer par lui .

      Si vous avez des idées,des tests à éffectuer .

      Meric d'avance

      @bientot sur pfsense.fr pour tutos et doc en fr avec l'accord de chris .

      1 Reply Last reply Reply Quote 0
      • J
        Juve
        last edited by

        surement un probleme de configuration au niveau du masque réseau, soit sur les postes soit sur le serveur TSE. le masque ne concorde pas avec la réalité et le trafic veut passer par la passerelle par défaut.

        1 Reply Last reply Reply Quote 0
        • R
          ritek
          last edited by

          Je vais verifier mais à priori je mets en masque 255.255.252.0 ,aprés le serveur tse c'est une societé qui le gére ,mais je vois pas pourquoi
          en mettant juste la livebox pro inventel ca passe nickel .

          1 Reply Last reply Reply Quote 0
          • R
            ritek
            last edited by

            Bonjour,

            J'ai vérifié les masques sous-réseaux .
            Sur les postes ils sont bons 255.255.252.0

            Le problème vient du boitier qui link le serveur TSE avec le lan ,c'est un smc qui n'accepte pas le masque 255.255.252.0 mais 255.255.255.0
            le serveur est en 10… et le boitier en 192.168.0.219 nat le tout sur mon lan .je ne peux pas le changer car il appartient a une société qui gère cette partie.
            Quoiqu'il en soit le problème doit être ailleurs car si je ne mets que la livebox ou si je désactive pf (Disable all packet filtering) dans systeme/advanced de pfsense je n'ai plus de problème.Si quelqu'un a une idée pour contourner le problème .

            Tia

            1 Reply Last reply Reply Quote 0
            • J
              Juve
              last edited by

              Dans la règle qui laisse passer le flux RDP, as-tu essayé de placer la gestion d'état à none (par défaut c'est keep state) pour désactiver la statefull inspection ?

              1 Reply Last reply Reply Quote 0
              • R
                ritek
                last edited by

                Salut,

                je viens d'essayer ,mais toujours les mêmes symptômes .
                Juste pour être sur,quand tu dis le flux RDP ,tu entends quoi ? Créer une règle RDP avec SI sur none ?
                Car la pour être sur de mon coup j'ai laissé la règle par défaut (lan any )et j'ai testé en SI sur none.
                Je vais essayer de mettre une wrap monowall pour tester vite fait si j'ai les mêmes problèmes .

                Merci de ton aide ,

                1 Reply Last reply Reply Quote 0
                • R
                  ritek
                  last edited by

                  Sur la wrap monowall ,c'est encore plus space .Si je ne suis pas en 192.168.0.* ,il n'essaie même pas de se connecter au TSE .

                  1 Reply Last reply Reply Quote 0
                  • J
                    Juve
                    last edited by

                    Si le boitier est en 255.255.255.0 il essaira toujours de répondre en dirigeant ses paquets vers sa passerelle par défaut pour tous les clients qui ont un 3eme octet différent du sien. Dès lors il y a problème, le flux aller est direct et le flux retour est dirigé vers la pfsense.

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