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

    Bug? IPv6 Virtual subnet not added to interface subnet

    Scheduled Pinned Locked Moved HA/CARP/VIPs
    7 Posts 2 Posters 538 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
      ngsk
      last edited by

      We added two (routable) IP ranges as a Virtual IP (no CARP, single firewall node)

      1. IPv4 range
      2. IPv6 range

      Both in their own Virtual IP definition.

      Only the extra IPv4 range is added as an extra subnet to the interface (OPT1_network we called DMZ). The IPv6 range is not.

      How do we know this is the case? We checked the #System aliases tables in /tmp/rules.debug.
      Any rules involving the (builtin) "$interface subnets" reference will not apply to the extra IPv6 subnet, breaking filtering expectations.

      Note: the virtual IP address is configured as an extra (V)IP on the interface itself.

      We run version 2.7.1 CE.

      This looks like a bug to us.

      1 Reply Last reply Reply Quote 0
      • S
        sbs
        last edited by

        Hi,

        Same issue here.

        Addiing IPV6 to our pfsense (v2.7) ipv6 works fine, except that vipv6 do not seem to work and be routed by the FW..

        Did you ever get an answer?

        N 1 Reply Last reply Reply Quote 0
        • N
          ngsk @sbs
          last edited by

          @sbs I updated this redmine Issue I created a long time ago (which I had forgotten about): redmine 8386. Maybe it's better to add a new issue to get this addressed.

          S 1 Reply Last reply Reply Quote 0
          • S
            sbs @ngsk
            last edited by

            @ngsk :

            Hi, Thank you for the reply. However, since I am pretty new to ipv6 and this issue seems old, I am still assuming I am misconfiguring.
            My setup is as follows :
            a50a6342-6500-4077-8601-46ee31f0fb5e-image.png

            WAN IP is ...:1000::1
            LAN IP is ...:1001::1
            LAN VirtIP is ...:1002::1

            RA advertises nets 1001 & 1002 on lan side. LAN Side works fine.
            VPN Works but only to 1001/64 LAN subnet.
            1002 subnet LAN does not access internet going out.
            no one can ping ...:1002::1
            I created the ipv6 virtualIP in alias gui menu the same way I did for my ipv4 virtual IPs. (Except that IPV4 virtual IPs are all on the WAN Side, and not on the LAN side)

            Am I missing something obvious here?

            Something a litlle weird is that if I tracert from my vpn client to an AD Server IP the 1st step is the openvpn entry point ....:1003::1 and at the same time the firewall log fills with blocks packets to AD server port 389 from my vpn client on the WAN side.

            N 1 Reply Last reply Reply Quote 0
            • N
              ngsk @sbs
              last edited by

              @sbs What firewall rules do you use for allowing vpn traffic to AD servers?

              The workaround that I made was adding an "alias" with all the networks that are attached on the (LAN) interface and use that alias in firewall rules (as the bug won't add the virtual IPv6 range to the interface [NET])

              S 1 Reply Last reply Reply Quote 0
              • S
                sbs @ngsk
                last edited by

                @ngsk

                As a matter of fact, I have set a rule for all LAN subnet ranges :)

                My vpn ruleset is very limited :
                aee043bc-5206-4e6f-8226-3fe3675fa80d-image.png

                Openbar style.

                S 1 Reply Last reply Reply Quote 0
                • S
                  sbs @sbs
                  last edited by

                  FWIW : I have moved all AD Server to the dhcp lan subnet, removed the ra server configuration, removed the virtual IP to have a second subnet, and all works flowlessly.

                  It seems ipv6 virtual ip routing is not working as expected on the LAN side.

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