Navigation

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

    Need fresh eyes for routing between vlans

    Routing and Multi WAN
    3
    6
    1321
    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.
    • A
      alefrenz last edited by

      Hi Everybody,
      this is my first topic. I'm a pfsense noob and i need your help to finalize my setup.
      I have attached my network topology…i hope is clear...
      I have installed pfsense on a 4NIC machine:
      igb0 WAN (poppe DSL connection)
      igb1 LAN 192.168.1.9/24 with DSL gateway (WAN)
      nvpnc1 VPN (openVPN interface)
      igb2 VPNLAN 192.168.99.0/24 with VPN gateway
      igb3 not used

      Now in between the hosts and the firewall there is a Cisco switch configured to tag the VLANs 1 and 99.

      Everything work perfectly and all the traffic is routed to the gateway WAN or VPN based on the VLAN
      The only issue i have is that i want the VLAN hosts to be able to communicate each other but after couple of days playing with rules and NAT i really need a fresh look of someone else.

      Thanks in advance for help and suggestions
      ale


      1 Reply Last reply Reply Quote 0
      • H
        heper last edited by

        you generally don't specify gateways on any LAN interface

        1 Reply Last reply Reply Quote 0
        • Derelict
          Derelict LAYER 8 Netgate last edited by

          It looks like they might be a reference to the gateways set for policy routing on those interfaces.

          You generally can't tag VLAN 1 either. When you start tagging VLANs pretend VLAN 1 does not exist.

          If you want to use two router ports to go to two different VLANs on a switch you can. But if you do not create the VLANs on the router interfaces, the switch ports should be untagged.

          In that case it's safe to use VLAN 1 for one of them.

          In your diagram there is no reason to use any VLAN tags at all

          int fast 0/0
          switchport mode access
          switchport access vlan 1 (I think you can do that. It's been forever since I did anything with vlan 1)

          int fast 0/1
          switchport mode access
          switchport access vlan 99

          connect igb1 to fast0/0 and igb2 to fast0/1

          Do the same above on two more ports and connect your devices.

          int fast 0/2
          switchport mode access
          switchport access vlan 1

          Connect something there and it will be on 192.168.1.0/24

          int fast 0/3
          switchport mode access
          switchport access vlan 99

          Connect something there and it will be on 192.168.99.0/24

          Apologies if this is totally different than your switch. I don't have any 28XX switches.

          1 Reply Last reply Reply Quote 0
          • A
            alefrenz last edited by

            thank you both for the input.
            I specify gateways to LAN interfaces to force traffic LAN->WAN and LANVPN->VPN
            Mainly the switch posts are tagged like this:

            interface GigabitEthernet0/11
            switchport access vlan 99
            switchport mode access

            Your right VLAN1 is default on cisco and no tag! i will move it on VLAN10

            As a said all the traffic goes as expected to the right gateway…but still i cannot ping 192.168.1.0 from 192.168.99.0 or vice versa.
            I spent so much time trying to create policy routing rules in pfsense that at the moment i restored the default rules...if you have any rule in  mind that permit the communication between these two network i will be happy!
            thanks

            1 Reply Last reply Reply Quote 0
            • Derelict
              Derelict LAYER 8 Netgate last edited by

              Ah sounds like you're missing bypassing policy routing. You need a rule on LAN that passes all traffic source LAN net dest VPNLAN net with gateway default. You also need a rule on VPNLAN that passes all traffic source VPNLAN net dest LAN net gateway default.

              These rules need to be above the rules that send traffic to WAN or the VPN.

              1 Reply Last reply Reply Quote 0
              • A
                alefrenz last edited by

                Thank you very much for the suggestions!
                Finally i opted for a different solution…
                I have created a LAGG interface for igb1+igb2 and trunk ports on cisco switch...applied the VLAN tags and everything is now working as expected!

                1 Reply Last reply Reply Quote 0
                • First post
                  Last post

                Products

                • Platform Overview
                • TNSR
                • pfSense
                • Appliances

                Services

                • Training
                • Professional Services

                Support

                • Subscription Plans
                • Contact Support
                • Product Lifecycle
                • Documentation

                News

                • Media Coverage
                • Press
                • Events

                Resources

                • Blog
                • FAQ
                • Find a Partner
                • Resource Library
                • Security Information

                Company

                • About Us
                • Careers
                • Partners
                • Contact Us
                • Legal
                Our Mission

                We provide leading-edge network security at a fair price - regardless of organizational size or network sophistication. We believe that an open-source security model offers disruptive pricing along with the agility required to quickly address emerging threats.

                Subscribe to our Newsletter

                Product information, software announcements, and special offers. See our newsletter archive to sign up for future newsletters and to read past announcements.

                © 2021 Rubicon Communications, LLC | Privacy Policy