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

    VLAN Issue

    Scheduled Pinned Locked Moved 2.1 Snapshot Feedback and Problems - RETIRED
    38 Posts 7 Posters 12.8k 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.
    • M
      markuhde
      last edited by

      @timthetortoise:

      Could someone post their netstat -rn output on a box with a working OpenVPN config?

      Edit: nevermind, found out one of my switches' configs got changed by someone who doesn't like to inform other people why they're doing stupid stuff, so my route was gone. I am not having the VPN/firewall issue.

      That's great, I'm wondering if my issue has to do with the cheap MicroTik switch the firewall is connected to. I was successfully talking from OpenVPN to LAN and now it's quit working again. Here is my netstat -rn if it's useful:

      [2.1-BETA1][admin@glacierfire.glaciercamp]/root(1): netstat -rn
      Routing tables
      
      Internet:
      Destination        Gateway            Flags    Refs      Use  Netif Expire
      default            72.250.187.1       UGS         0   684815    em1
      72.160.38.1        link#11            UH          0    54778 pppoe0
      72.160.38.69       link#11            UHS         0        0    lo0
      72.250.187.0/24    link#3             U           0   113694    em1
      72.250.187.21      link#3             UHS         0        0    lo0
      127.0.0.1          link#6             UH          0     1363    lo0
      172.16.16.0/22     link#9             U           0  1520856 em0_vl
      172.16.16.1        link#9             UHS         0        0    lo0
      172.21.12.0/22     link#8             U           0   311550 em0_vl
      172.21.12.1        link#8             UHS         0        0    lo0
      172.21.16.0/24     172.21.16.2        UGS         0    15315 ovpns1
      172.21.16.1        link#12            UHS         0        0    lo0
      172.21.16.2        link#12            UH          0        0 ovpns1
      192.168.41.0/24    link#10            U           0       33 em0_vl
      192.168.41.1       link#10            UHS         0        0    lo0
      
      Internet6:
      Destination                       Gateway                       Flags      Netif Expire
      ::1                               ::1                           UH          lo0
      fe80::%re0/64                     link#1                        U           re0
      fe80::d227:88ff:feba:d2e%re0      link#1                        UHS         lo0
      fe80::%em0/64                     link#2                        U           em0
      fe80::204:23ff:feac:cf84%em0      link#2                        UHS         lo0
      fe80::%em1/64                     link#3                        U           em1
      fe80::204:23ff:feac:cf85%em1      link#3                        UHS         lo0
      fe80::%lo0/64                     link#6                        U           lo0
      fe80::1%lo0                       link#6                        UHS         lo0
      fe80::%em0_vlan69/64              link#8                        U      em0_vlan
      fe80::d227:88ff:feba:d2e%em0_vlan69 link#8                        UHS         lo0
      fe80::%em0_vlan15/64              link#9                        U      em0_vlan
      fe80::d227:88ff:feba:d2e%em0_vlan15 link#9                        UHS         lo0
      fe80::%em0_vlan763/64             link#10                       U      em0_vlan
      fe80::d227:88ff:feba:d2e%em0_vlan763 link#10                       UHS         lo0
      fe80::%pppoe0/64                  link#11                       U        pppoe0
      fe80::d227:88ff:feba:d2e%pppoe0   link#11                       UHS         lo0
      fe80::%ovpns1/64                  link#12                       U        ovpns1
      fe80::d227:88ff:feba:d2e%ovpns1   link#12                       UHS         lo0
      ff01::%re0/32                     fe80::d227:88ff:feba:d2e%re0  U           re0
      ff01::%em0/32                     fe80::204:23ff:feac:cf84%em0  U           em0
      ff01::%em1/32                     fe80::204:23ff:feac:cf85%em1  U           em1
      ff01::%lo0/32                     ::1                           U           lo0
      ff01::%em0_vlan69/32              fe80::d227:88ff:feba:d2e%em0_vlan69 U      em0_vlan
      ff01::%em0_vlan15/32              fe80::d227:88ff:feba:d2e%em0_vlan15 U      em0_vlan
      ff01::%em0_vlan763/32             fe80::d227:88ff:feba:d2e%em0_vlan763 U      em0_vlan
      ff01::%pppoe0/32                  fe80::d227:88ff:feba:d2e%pppoe0 U        pppoe0
      ff01::%ovpns1/32                  fe80::d227:88ff:feba:d2e%ovpns1 U        ovpns1
      ff02::%re0/32                     fe80::d227:88ff:feba:d2e%re0  U           re0
      ff02::%em0/32                     fe80::204:23ff:feac:cf84%em0  U           em0
      ff02::%em1/32                     fe80::204:23ff:feac:cf85%em1  U           em1
      ff02::%lo0/32                     ::1                           U           lo0
      ff02::%em0_vlan69/32              fe80::d227:88ff:feba:d2e%em0_vlan69 U      em0_vlan
      ff02::%em0_vlan15/32              fe80::d227:88ff:feba:d2e%em0_vlan15 U      em0_vlan
      ff02::%em0_vlan763/32             fe80::d227:88ff:feba:d2e%em0_vlan763 U      em0_vlan
      ff02::%pppoe0/32                  fe80::d227:88ff:feba:d2e%pppoe0 U        pppoe0
      ff02::%ovpns1/32                  fe80::d227:88ff:feba:d2e%ovpns1 U        ovpns1
      
      
      1 Reply Last reply Reply Quote 0
      • T
        timthetortoise
        last edited by

        Can you run wireshark or tcpdump on the machine you're trying to get traffic to to verify that it's not getting through? Or do you know for a fact that none of the traffic is touching it?

        1 Reply Last reply Reply Quote 0
        • M
          markuhde
          last edited by

          @timthetortoise:

          Can you run wireshark or tcpdump on the machine you're trying to get traffic to to verify that it's not getting through? Or do you know for a fact that none of the traffic is touching it?

          Sadly I can't, since every "machine" on the network on a regular basis I control is a Wi-Fi AP or a small smart switch. I could, next time I'm on site, put a machine on it running wireshark and attempt to VPN in from my iPad… there's an OVPN iPad client now. I'll do that next time I'm on site if I get a chance to.

          1 Reply Last reply Reply Quote 0
          • T
            timthetortoise
            last edited by

            I honestly can't find anything wrong with your firewall or routing tables. Could you post a simplified version of your topology when you get a chance? If you have an intermediary L3 device, I'm thinking your issue may be similar to what was going on with me, but I don't believe at this point that it's pf's fault.

            1 Reply Last reply Reply Quote 0
            • M
              markuhde
              last edited by

              Okay here's the basic text description:

              WAN 1 is Montana Digital (mtdig.net) 72.250.187.21
              WAN 2 is CenturyLink PPPoE
              both feed into pfSense
              Local side of pfSense is one port - three VLAN's. VLAN 69 - 172.21.12.1/22, VLAN 15 - 172.16.16.1/22, VLAN 763 - 192.168.41.1/24

              This feeds a MikroTik RB 250/GS 5-port switch.
              One of these ports feeds a Raspberry Pi (and is a VLAN 69 access port) for RADIUS
              The rest are trunk ports of which two are used (one free port):
              One feeds a Trendnet PoE 8-port switch which feeds an EnGenius ENH-200, a Trendnet TEW-653AP and a Buffalo WHR-HP-G300N

              One feeds another building which has a small 8-port ASUS Gigabit Unmanaged Switch which in turn feeds:
              A EnGenius EAP-600
              A Buffalo WHR-HP-G300N
              An EnGenius ENH-202
              An Ubiquiti Nanostation M5 in WDS-AP mode

              The Nanostation M5 has three clients in WDS-STA mode, which feed:

              Nanostation Loco M5 #1:
              Another ASUS unmanaged switch connected to:
              EnGenius ENH-202
              EnGenius ENH-500
              EnGenius EAP-300

              Nanostation Loco M5 #2:
              Another MikroTik RB/250GS feeding:
              Trunk: Trendnet PoE switch connected to an EnGenius EAP600 (more devices to come, LOL)
              Access 763: Audio DSP (forgot the make/model)
              Access 763: Buffalo WHR-HP-G300N

              Nanostation Loco M5 #3:
              Buffalo WHR-HP-G300N

              All except the AP for the sound techs are on receiving all VLAN's and set to management on VLAN 69. This has all worked very well historically, I reinstalled pfSense and upgraded from a snap several months old when I needed to add a new NIC to support the second  WAN connection. (which itself is a pain, I didn't know Squid didn't load balance so I'm trying to learn how to do that, but that's unrelated obviously)

              1 Reply Last reply Reply Quote 0
              • T
                timthetortoise
                last edited by

                No intermediary L3 devices, can't get traffic that originates on the VPN side through, I'm stumped. Unless your default gateway is wrong on your machines (I'm assuming it's the pfSense IP for each respective VLAN), I can't find a reason your configuration isn't working without knowing your network/config more in-depth. Good luck with it!

                1 Reply Last reply Reply Quote 0
                • M
                  markuhde
                  last edited by

                  @timthetortoise:

                  No intermediary L3 devices, can't get traffic that originates on the VPN side through, I'm stumped. Unless your default gateway is wrong on your machines (I'm assuming it's the pfSense IP for each respective VLAN), I can't find a reason your configuration isn't working without knowing your network/config more in-depth. Good luck with it!

                  Default gateway is the pfSense IP for VLAN_69 on everything. I think I've tracked down the problem as an OpenVPN issue though more than a firewall issue. All that testing was with the OpenVPN client for Windows which had been working and suddenly stopped with no config changes (couldn't get traffic to anything). I just installed the client for iPad and for Android. Lots of random disconnects, especially on the Android version, but both 95% work - definitely enough to be usable for my purposes. I changed NOTHING on the Windows client from when it was working though. I sure wish the OpenVPN setup on pfSense worked with Fedora (it doesn't even let you try because there's no certificate password).

                  So, it seems the only issue I'm having that's actually possibly VLAN caused (I still need to figure out load balancing Squid but that's obviously a topic for another thread) is need for the seemingly redundant allow from any rule on the LAN side (since as said, established states should just be allowed).

                  Thanks for the good wishes on sorting this out :) I really am trying to be as useful as I can be with this.

                  1 Reply Last reply Reply Quote 0
                  • M
                    mikeisfly
                    last edited by

                    Can you make a network diagram? gliffy.com . Are you seeing the mac address of the default gateways on the various subnets? (arp -a in windows will show you your arp table) Not sure how to do it in FreeBSD. I'm thinking that you might have a switching loop on your network. Also are your trunk ports tagged vlan ports. Are you sending tagged traffic to a end device? Most computers and access points will drop tagged traffic unless they are configured to deal with the extra 4 bytes. I like a puzzle, looking forward to seeing your diagram.

                    1 Reply Last reply Reply Quote 0
                    • M
                      markuhde
                      last edited by

                      @mikeisfly:

                      Can you make a network diagram? gliffy.com . Are you seeing the mac address of the default gateways on the various subnets? (arp -a in windows will show you your arp table) Not sure how to do it in FreeBSD. I'm thinking that you might have a switching loop on your network. Also are your trunk ports tagged vlan ports. Are you sending tagged traffic to a end device? Most computers and access points will drop tagged traffic unless they are configured to deal with the extra 4 bytes. I like a puzzle, looking forward to seeing your diagram.

                      I'm adding a few AP's and a couple more little MikroTik switches to create access ports NEXT weekend but as of today, here's how it looks:

                      http://www.gliffy.com/go/publish/4535154/

                      The access points are configured to deal with tagged traffic as we run separate SSID's on each VLAN. Nobody is plugging into a trunk port directly (nobody gets to come in and plug into ANY port anymore for that matter since the switches that accomplished that broke)

                      P.S. As I noted this same basic setup used to work perfectly fine without any "extra" rules. Thanks a ton for your help! It seems to be mostly working now, I think all my OpenVPN issues are actually my internet connection where I live.

                      1 Reply Last reply Reply Quote 0
                      • M
                        mikeisfly
                        last edited by

                        Okay if you said it's working then I will leave enough alone. I know you said it worked before but from your diagram you are using unmanaged switches with shouldn't pass tagged traffic. No if they are on access ports assigned to specific vlans then there should be no problem there. However if you send tagged traffic into a access port most unmanaged switches I would think would drop it. Just something to look at. Just wanted to offer my input, let me know if I could be of any further assistance? By the way I have a EnGenius EAP 600 Access Point in my house, that is a sweet piece of gear.

                        1 Reply Last reply Reply Quote 0
                        • M
                          markuhde
                          last edited by

                          @mikeisfly:

                          Okay if you said it's working then I will leave enough alone. I know you said it worked before but from your diagram you are using unmanaged switches with shouldn't pass tagged traffic. No if they are on access ports assigned to specific vlans then there should be no problem there. However if you send tagged traffic into a access port most unmanaged switches I would think would drop it. Just something to look at. Just wanted to offer my input, let me know if I could be of any further assistance? By the way I have a EnGenius EAP 600 Access Point in my house, that is a sweet piece of gear.

                          MOST unmanaged switches pass tagged traffic just fine. They don't do anything with the tags, nor do they need to in this application. Some will drop tagged frames, but they generally don't - and shouldn't. They aren't smart enough to know what the tags are, and if behaving properly they just ignore them.

                          It seems to be working okay now, though I had to roll back last night's pfSense snap - I made a new thread for that!

                          Yes, the EAP600 is very nice, I was a beta tester for them and they're fantastic for the price. They've got a removable-antenna version the ECB600 coming soon.

                          1 Reply Last reply Reply Quote 0
                          • M
                            markuhde
                            last edited by

                            This affects this particular install so little, I haven't had time to worry about it - but I still can't get traffic between interfaces at all most of the time (sometimes it works, the extra rule had nothing to do with it, it's actually rather random, and hasn't worked in weeks). I'm on the latest snapshot tonight and… nothing. Firewall to any address is fine. Any address to another interface's firewall address is fine. Any LAN interface out to the Internet is fine. But pinging a machine on another LAN interface or connecting to it in any way? Just silently blocked (it doesn't show up in the firewall logs, it just doesn't work).

                            I'm at a total loss for why - my rules should definitely be allowing this traffic to the best of my understanding.

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