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

    VLAN, PPTP server … working, with issues

    Scheduled Pinned Locked Moved 1.2.1-RC Snapshot Feedback and Problems-RETIRED
    10 Posts 6 Posters 6.3k 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.
    • N
      NUT
      last edited by

      I've discovered a problem in the latest RC2 snapshots. Snapshot pfSense-Full-Update-1.2.1-RC1-20080817-2330.tgz was the last (correctly working version) I installed before updating to pfSense-Full-Update-1.2.1-RC2-20081105-0856.tgz and running into a strange PPTP 'trap' situation.

      To create an understanding of how the working conditions are, here is a rundown of our equipment and connections:

      I hope it is clear this way.

      Note to keep in mind: The VLAN's have been created recently (past few days) to accomodate the Classroom LAN. This is the reason why it never happened before. The problem did not exsist before we updated to pfSense-Full-Update-1.2.1-RC2-20081105-0856.tgz.

      Problem: PPTP clients can no longer reach IP addresses on the LAN (VLAN0), but are able to ping amongst eachother. They can also visit the outside world. They can ping the pfSense LAN ip aswell… but that's as far as they go!

      Besides that the Dashboard package does nolonger work on the latest snapshot.

      1 Reply Last reply Reply Quote 0
      • valnarV
        valnar
        last edited by

        Make sure you notify the devs directly.

        Thanks.

        1 Reply Last reply Reply Quote 0
        • GruensFroeschliG
          GruensFroeschli
          last edited by

          @http://forum.pfsense.org/index.php/topic:

          Do notPM developers unless you have some really complicated issues, and allways ask nicely before filling mailboxes and other communication channels with questions, and if you got no answer it means your request was denied, keep bugging devs privately and you might find yourself the happy owner of BANS/Ignores and other nice "features".

          If you don't get an answer within 5 minutes don't be demanding ("anyone?")! If you don't get one there is possibly a reason (noone ever had the problem / no time to answer / no clue / language barrier / something more important to do / … ).

          [NUT] posted his issue in the correct subforum (feedback on 1.2.1) and 24 hours havent passed.

          From the diagram you posted i see you're using the VLAN ID1.
          You should under no circumstance do that.
          VLAN1 is the default VLAN. It might well be, that this is your only problem.
          Could you try to move your VLANs to 100 and 200 or something like this and try again?

          We do what we must, because we can.

          Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

          1 Reply Last reply Reply Quote 0
          • B
            blak111
            last edited by

            I don't believe that using VLAN id 1 would be the cause of a failure after an update when it worked fine before. It's frowned upon to use from a security stance but it's still functional, especially in such a small network.

            1 Reply Last reply Reply Quote 0
            • N
              NUT
              last edited by

              @GruensFroeschli:

              From the diagram you posted i see you're using the VLAN ID1.
              You should under no circumstance do that.
              VLAN1 is the default VLAN. It might well be, that this is your only problem.
              Could you try to move your VLANs to 100 and 200 or something like this and try again?

              VLAN ID1 is indeed is the default VLAN from the procurve switches. This is why i still use it. Why is it a bad thing to use it? It was the only way to make the pfSense-Full-Update-1.2.1-RC1-20080817-2330.tgz installation working as intended and make pfsense NOT crash on VLAN usage… (as i attempted to still use the physical NIC at that point, i know now that was the problem at that point why it would not work at the first attempt).

              @blak111:

              I don't believe that using VLAN id 1 would be the cause of a failure after an update when it worked fine before. It's frowned upon to use from a security stance but it's still functional, especially in such a small network.

              That was exactly the reason to use VLAN ID1: we have a fairly small network. Between the 2x 48 ports we have around 55 are permanently patched up and in use. Add the 20 for the classroom and that leaves some room to grow. Just because i am the VLAN newbie, i'm going to ask: Why is it frowned upon from a security point of view?

              1 Reply Last reply Reply Quote 0
              • GruensFroeschliG
                GruensFroeschli
                last edited by

                All traffic arriving on ports not part of a VLAN will be treated like it's part of VLAN1.

                I actually had that happen to me that i mixed tagged and untagged traffic on the same switch.
                Two devices which should communicate over pfSense, were able to "find" themself directly.
                Now they tried to send traffic directly to each other, but one of them was sending untagged traffic while the other expected tagged traffic.

                However i'm not sure if this really is your problem since you say it worked before.

                We do what we must, because we can.

                Asking questions the smart way: http://www.catb.org/esr/faqs/smart-questions.html

                1 Reply Last reply Reply Quote 0
                • jahonixJ
                  jahonix
                  last edited by

                  @GruensFroeschli:

                  However i'm not sure if this really is your problem since you say it worked before.

                  IIRC there has been work on VLANs recently. That could explain why it is behaving differently afterwards.

                  1 Reply Last reply Reply Quote 0
                  • B
                    blak111
                    last edited by

                    The security concerns with VLAN 1 are mainly just because it is the default VLAN used for everything on the switches, like management, CDP, unassigned ports, etc. It's a lot harder to make sure you have everything in VLAN 1 tightened down and pruned correctly in large switched networks rather than to create user VLANs where nothing is on them from the start.
                    On Cisco setups, when you form a trunk to a switch, all untagged traffic gets passed onto the native VLAN for that trunk which is VLAN 1 unless it is explicitly configured to use another. This could lead to the situation that Gruens was talking about. If a host had a tagged link to it, it would receive traffic from whatever VLANs are traveling down that link, and when it would go to respond, it's traffic would pass back out onto VLAN 1 rather than the VLAN it received the traffic from.

                    1 Reply Last reply Reply Quote 0
                    • C
                      cmb
                      last edited by

                      Not using VLAN 1 also protects against VLAN hopping attacks, as depending on your switch and its configuration, it can be easy to get dropped into the default VLAN from another VLAN (via double tagging and other measures). If that VLAN is unused, it doesn't matter.

                      There were some VLAN changes, but they fixed numerous problems with VLANs introduced by changes in FreeBSD 7.0. All VLAN deployments managed by the developers work fine now, as do all others we know of.

                      @[NUT:

                      link=topic=12485.msg67713#msg67713 date=1226069482]
                      Note to keep in mind: The VLAN's have been created recently (past few days) to accomodate the Classroom LAN. This is the reason why it never happened before. The problem did not exsist before we updated to pfSense-Full-Update-1.2.1-RC2-20081105-0856.tgz.

                      This isn't clear to me - does it just not work now that you added VLANs, or did the VLANs work fine in the previous version and when you upgraded they stopped working?

                      1 Reply Last reply Reply Quote 0
                      • N
                        NUT
                        last edited by

                        To all who explained VLAN ID1 / Default VLAN to me: thank you, i'll have a second look at the configuration the comming week.

                        @cmb:

                        This isn't clear to me - does it just not work now that you added VLANs, or did the VLANs work fine in the previous version and when you upgraded they stopped working?

                        Its not that the VLAN's are not working, they are, its just that the PPTP clients are nolonger able to reach the LAN clients and servers… though after reading GruensFroeschli's reply about the tagged/untagged traffic problems he had i am starting to suspect that might be the case for this problem aswell... The pfSense port has been set to 'tagged' and the win2k domain is mostly on 'untagged' ports (as they would be using the default VLAN).

                        I'm going to play with the VLANs a bit more the comming week, i'll have a redraw on the network implementation and will give it a new go. I'll update this thread if it solved the problems we experienced or not.

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