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

    Send all traffic from VLAN out VPN interface.

    Routing and Multi WAN
    3
    19
    4.0k
    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.
    • J
      JimPhreak
      last edited by

      @jahonix:

      Either use VLAN100 & VLAN200 tagged on the same pfSense port and feed a trunk to your switch OR
      use two interfaces with untagged traffic and connect two separate cables to your switch.

      The latter is only needed if you want to push more than ~700Mb/s through an interface.

      I can't even seem to get that far.  I assigned my LAN interface to VLAN110 as seen below and enabled DHCP on it.  However I can't get an IP from DHCP even though it's enabled on the interface.  And I can only communicate with a static if I tag the port from the switch to pfSense LAN in VLAN 110.  Untagging it in VLAN110 makes me unable to communicate.

      Clearly I'm doing something wrong.

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

        What you're seeing is completely expected.  Tagged ports need to talk to tagged ports.  Look at the diagram I posted again.

        @JimPhreak:

        @Derelict:

        correcting the tagged pfSense ports to untagged switch ports, of course

        I'm a little confused by what you meant by this.

        In you original description you had:

        pfSense igb1:  LAN (with VLAN100 assigned)

        connected to

        Switch 1 Port 1:  connected to igb1 (untagged in VLAN100)

        I can only interpret that as a pfSense tagged port connected to an untagged switch port.  That won't work.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

          @Derelict:

          What you're seeing is completely expected.  Tagged ports need to talk to tagged ports.  Look at the diagram I posted again.

          @JimPhreak:

          @Derelict:

          correcting the tagged pfSense ports to untagged switch ports, of course

          I'm a little confused by what you meant by this.

          In you original description you had:

          pfSense igb1:  LAN (with VLAN100 assigned)

          connected to

          Switch 1 Port 1:  connected to igb1 (untagged in VLAN100)

          I can only interpret that as a pfSense tagged port connected to an untagged switch port.  That won't work.

          Yea figured that out late last night, thanks for pointing that out.

          I've decided to go with single physical interface for both VLANs.  I've got both VLANs setup, DHCP enabled on both and the switches are properly tagged and passing traffic (devices getting DHCP addresses and can talk between VLANs).

          This is where I'm at and I'm trying to determine where to go from here.

          I want all traffic coming from the AIRVPN_LAN network (Media Server) to go out the AIRVPN_WAN interface instead of my regular WAN.  If the AIRVPN_WAN was to go down I'd like no traffic to go out my regular WAN.

          I'm not sure the best way to go about configuring NAT and Firewall rules to accomplish this.  The way I have it configured above, I can't get out to the internet from any AIRVPN_LAN address.

          Some basic guidelines here would be real helpful.

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

            Turn on Automatic Outbound NAT.  Having the NAT entries there is harmless if you don't send traffic out that port.  What you want is WAN configured as the default gateway, policy routes on AIRVPN_LAN sending the desired traffic out the VPN gateway, with possible policy route bypassing for local and or other traffic, then a mechanism to assure VPN traffic doesn't go out WAN, which is in the third link.

            Then:

            https://doc.pfsense.org/index.php/What_is_policy_routing

            And

            https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

            And

            https://forum.pfsense.org/index.php?topic=84463.msg463226#msg463226

            And countless threads in the OpenVPN forum talking about sending certain traffic out a tunnel.  I mean like every day.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

              @Derelict:

              Turn on Automatic Outbound NAT.  Having the NAT entries there is harmless if you don't send traffic out that port.  What you want is WAN configured as the default gateway, policy routes on AIRVPN_LAN sending the desired traffic out the VPN gateway, with possible policy route bypassing for local and or other traffic, then a mechanism to assure VPN traffic doesn't go out WAN, which is in the third link.

              Then:

              https://doc.pfsense.org/index.php/What_is_policy_routing

              And

              https://doc.pfsense.org/index.php/Bypassing_Policy_Routing

              And

              https://forum.pfsense.org/index.php?topic=84463.msg463226#msg463226

              And countless threads in the OpenVPN forum talking about sending certain traffic out a tunnel.  I mean like every day.

              When I turn on Automatic NAT as you say and then setup a policy route like you see below (just for testing purposes), devices on the AIRVPN_LAN can't get out to the internet.

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

                Ah.  I guess Automatic doesn't make NAT rules for the VPN gateway.  You might consider Hybrid with one rule on AIRVPN_WAN, source subnet of AIRVPN_LAN, NAT address AIRVPN_WAN address.  Then as you make other changes over time auto NAT will continue to do its thing.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                  @Derelict:

                  Ah.  I guess Automatic doesn't make NAT rules for the VPN gateway.  You might consider Hybrid with one rule on AIRVPN_WAN, source subnet of AIRVPN_LAN, NAT address AIRVPN_WAN address.  Then as you make other changes over time auto NAT will continue to do its thing.

                  Got it.  Thanks for the links I got everything setup as you outlined except one issue.  As soon as I set that Floating Firewall rule tagged NO_WAN_EGRESS I disables all internet traffic from all networks for me.  I've make sure I only tagged the Floating Rule and the Rule that allows traffic out my AIRVPN_WAN but yet enabling it blocks all traffic out my regular WAN.  Am I missing an additional rule somewhere?

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

                    You need to make sure you are not TAGGING on the floating rule but MATCHING the tag.  You mark it on the policy rule on AIRVPN_LAN and match it on the floating rule.  If you mark in both places you will block all traffic outbound on WAN.

                    Chattanooga, Tennessee, USA
                    A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                    DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                    Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                      @Derelict:

                      You need to make sure you are not TAGGING on the floating rule but MATCHING the tag.  You mark it on the policy rule on AIRVPN_LAN and match it on the floating rule.  If you match in both places you will block all traffic outbound on WAN.

                      Ahhhh, good catch!  Well that works well, sweet.

                      Now if I could just get my port forward over the AIRVPN_WAN interface to work.  I posted in the NAT section on that though.  Thanks a lot for your help it's been HUGE!

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

                        You know you have to assign an interface to the OpenVPN client instance in order to NAT on it right?  Search on OpenVPN Assigned Interface.

                        Chattanooga, Tennessee, USA
                        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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