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

    Vlan and cisco slm2008

    Scheduled Pinned Locked Moved General pfSense Questions
    12 Posts 3 Posters 4.6k 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.
    • B
      bastardz
      last edited by

      I have problem with vlan. I've read documentation and forum posts and tried lot of option but it still doesn't work.

      Here is my cisco vlan settings

      pfsense is connected to port 1 on switch
      raspberry is connected to port 6 on switch

      here is my pfsesnse vlan settings

      VLAN 100 interface has ip 192.168.20.2

      Now I try to ping from Diagnostic->Ping
      192.168.20.1 (raspberry)
      but raspberry is not responding.

      what am i doing wrong?
      p.s How can I check that my LAN card is VLAN capable ?

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

        Are you sure the Raspberry responds to ping requests?

        Can you connect a device to port g6 the is known to respond to g6 and give that a try?

        Are you sending the diagnostics ping on the correct interface (LAN)?

        For end point devices you may want to use Access mode.

        I put the WAN on VLAN and leave LAN to use the default untagged vlan 1.  There is fewer ports/connections involved with the WAN that need VLAN configuration.  And no configuration needed for LAN devices.

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

          Hi NOYB
          Thanks for your reply. This is my testing enviroment because I cant make it works on production pfsense.
          My end scenario is connect 3 ADSL modem to one single NIC on pfsense with help of SLM2008.

          In my testing enviroment Raspberry works as a ADSL modem and yes Raspberry respond to ping.
          When I am pinging from pfsense I set correct interface.
          Today I will add another NIC to my pfsense and connect Raspberry to WAN port thru cisco and my laptop to LAN port. This will be  exactly like on production architecture and show you my settings.

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

            Hi

            Ok I am lost. Have no idea what is wrong.
            Now I have two NIC one for WAN (VLANs) and one for LAN.

            LAN ip is 192.168.2.1
            WAN ip is 192.168.3.2
            WAN2 vlan 100 ip is 192.168.30.2

            cisco settings

            pfsense is connected to port g1
            Raspberry is connected to port g6

            Can't ping Raspberry from diagnostic->ping interfaces WAN2

            I've also tried to change NIC but still no luck.
            Any idea?

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

              Packet capture / sniffer.
              Firewall

              1 Reply Last reply Reply Quote 0
              • W
                wallabybob
                last edited by

                I am not familiar with the details of Cisco switch settings but I suspect port g6 shouldn't be a trunk port.

                It would be helpful to know:
                1. Is the ping going out the correct interface?
                2. Is the ping getting to raspberry?
                3. Is raspberry generating a response?
                4. Is the response getting to the correct interface?

                Packet capture can help answer these questions. pfSense has the a GUI interface for packet capture: Diagnostics -> Packet Capture and a command line utility: tcpdump.

                What OS does raspberry run?

                Did you restart pfSense after you changed the interfaces? (I have found that sometimes a restart is necessary to clear out "old" configuration information.)

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

                  Interface VLAN Mode—Select an option to configure the port type with respect to VLAN membership and tagging.

                  General—The port can be a member of one or more tagged or untagged VLANs. This mode allows the full capabilities specified in the IEEE 802.1Q specification, “VLAN Tagging.”

                  Access—The port can accept only untagged frames. An access port can be a member of only one VLAN and it uses the VLAN ID as its port VLAN ID (PVID). Access ports are typically used to connect hosts, which become members of the VLAN by virtue of being physically connected to the port.

                  Trunk—The port can be assigned to only one untagged VLAN, the native VLAN, and can be assigned to any number of tagged VLANs (or none). Trunk ports carry traffic for multiple VLANs from the switch to other network devices, such as an upstream router or an edge switch.

                  Although Access for the Blackberry connection port and General mode for the pfSense WAN connection port would probably be more appropriate.  Don't think Trunk mode should cause a problem in this case.  Think Trunk mode is default used by this switch.  Even for the default untagged management vlan 1.

                  It is time for some network captures to identify how far the ping requests/replys are getting (where they are being blocked).

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

                    Hi.
                    wallabybob and NOYB thanks for your reply and some hints.
                    I am step further.
                    I started ping from raspberry to pfsesne then I upgraded firmware on cisco and finally see some output of tcpdump.
                    My cisco setting now are as follow:

                    Before upgrade command "tcpdump -i re1_vlan100 -n -e -vv" shows nothing, right know:

                    tcpdump: listening on re1_vlan100, link-type EN10MB (Ethernet), capture size 96 bytes
12:38:42.186047 b8:27:eb:c4:36:b6 > 64:70:02:11:ab:5e, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
    192.168.30.1 > 192.168.30.2: ICMP echo request, id 3954, seq 1193, length 64

                    also

                    tcpdump -i re1 -n -e -vv shows tagged packet

                    tcpdump: listening on re1, link-type EN10MB (Ethernet), capture size 96 bytes
                    12:31:01.203161 b8:27:eb:c4:36:b6 > 64:70:02:11:ab:5e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
                        192.168.30.1 > 192.168.30.2: ICMP echo request, id 3954, seq 732, length 64
                    12:31:02.062324 20:bb:c0:78:83:32 > 01:80:c2:00:00:00, 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 8000.20:bb:c0:78:83:31.8001, length 43
                    message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
                    root-id 8000.20:bb:c0:78:83:31, root-pathcost 0, port-role Designated
                    12:31:02.203080 b8:27:eb:c4:36:b6 > 64:70:02:11:ab:5e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
                        192.168.30.1 > 192.168.30.2: ICMP echo request, id 3954, seq 733, length 64
                    12:31:03.203146 b8:27:eb:c4:36:b6 > 64:70:02:11:ab:5e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
                        192.168.30.1 > 192.168.30.2: ICMP echo request, id 3954, seq 734, length 64
                    12:31:04.063285 20:bb:c0:78:83:32 > 01:80:c2:00:00:00, 802.3, length 60: LLC, dsap STP (0x42) Individual, ssap STP (0x42) Command, ctrl 0x03: STP 802.1w, Rapid STP, Flags [Proposal, Learn, Forward, Agreement], bridge-id 8000.20:bb:c0:78:83:31.8001, length 43
                    message-age 0.00s, max-age 20.00s, hello-time 2.00s, forwarding-delay 15.00s
                    root-id 8000.20:bb:c0:78:83:31, root-pathcost 0, port-role Designated
                    12:31:04.202970 b8:27:eb:c4:36:b6 > 64:70:02:11:ab:5e, ethertype 802.1Q (0x8100), length 102: vlan 100, p 0, ethertype IPv4, (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto ICMP (1), length 84)
                        192.168.30.1 > 192.168.30.2: ICMP echo request, id 3954, seq 735, length 64

                    I still CANT ping raspberry from WAN2 and still CANT ping WAN2 from raspberry.

                    p.s

                    • I can ping raspberry if I connect my mac to raspberry.
                    • raspberry has latest Raspbian “wheezy”
                    • I added rule to WAN2 to pass everything
                    1 Reply Last reply Reply Quote 0
                    • W
                      wallabybob
                      last edited by

                      @bastardz:

                      I still CANT ping raspberry from WAN2

                      Does a tcpdump verify the ping goes out the correct interface with the correct VLAN tag? (I didn't see an answer to my question )Did you restart after changing the pfsense interfaces around?
                      Does a tcpdump on raspberry show the incoming ping request?

                      @bastardz:

                      and still CANT ping WAN2 from raspberry.

                      This might be easy to fix. You have added a firewall rule to allow that but did you reset firewall states after adding the rule? (See Diagnostics -> States, click on Reset States tab, read, remember and click the Reset button.)

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

                        Does a tcpdump verify the ping goes out the correct interface with the correct VLAN tag?

                        re1_vlan100: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                        options=3 <rxcsum,txcsum>ether 64:70:02:11:ab:5e
                        inet6 fe80::6670:2ff:fe11:a984%re1_vlan100 prefixlen 64 scopeid 0x9
                        inet 192.168.30.2 netmask 0xffffffff broadcast 192.168.30.2
                        nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
                        status: active
                        vlan: 100 parent interface: re1

                        When I ping from pfsense to raspberry

                        tcpdump show nothing on re1_vlan100 interface

                        [2.0.3-RELEASE][admin@pfSense.localdomain]/root(4): tcpdump -i re1_vlan100 -n -e -vv
tcpdump: listening on re1_vlan100, link-type EN10MB (Ethernet), capture size 96 bytes

                        I've also checked re1 and fxp0 if there is any echo but found nothing.

                        Did you restart after changing the pfsense interfaces around?

                        yes many many times

                        Does a tcpdump on raspberry show the incoming ping request?

                        No, nothing. ( I've also conneted raspberry to mac to verify that tcpdump shows echo and found it. )

                        This might be easy to fix. You have added a firewall rule to allow that but did you reset firewall states after adding the rule? (See Diagnostics -> States, click on Reset States tab, read, remember and click the Reset button

                        Did not help.
                        If i ping WAN2 from raspberry tcpdump on pfsense show tagged packet and echo request but WAN2 is not responding at all.
                        Here is my rule on WAN2
                        </full-duplex></performnud,accept_rtadv></rxcsum,txcsum></up,broadcast,running,simplex,multicast>

                        1 Reply Last reply Reply Quote 0
                        • W
                          wallabybob
                          last edited by

                          @bastardz:

                          re1_vlan100: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
                          options=3 <rxcsum,txcsum>ether 64:70:02:11:ab:5e
                          inet6 fe80::6670:2ff:fe11:a984%re1_vlan100 prefixlen 64 scopeid 0x9
                          inet 192.168.30.2 netmask 0xffffffff broadcast 192.168.30.2
                          nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>)
                          status: active
                          vlan: 100 parent interface: re1</full-duplex></performnud,accept_rtadv></rxcsum,txcsum></up,broadcast,running,simplex,multicast>

                          Why is the netmask 0xffffffff? 192.168.30.1 is NOT on the same subnet as re1_vlan100! I suggest you use a more conventional netmask such as 0xffffff00 so the subnet has enough IP addresses to be "interesting".

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

                            You are right.
                            After 5 days of fighting with this I made this small typo :)
                            Now it is working like a charm.
                            So for people having same issue with cisco SLM20XX you should upgrade firmware to 1.0.6.2 for VLAN working (and set correct netmask ;))

                            wallabybob and NOYB I really appreciate your help. Thank you.

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