Navigation

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

    Mixing IPv4 and IPv6 addresses in aliases not working as expected

    2.1 Snapshot Feedback and Problems - RETIRED
    5
    11
    2964
    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
      bl0815 last edited by

      I'm using pfsense  2.1-DEVELOPMENT, Built On: Fri May 18 05:58:04 EDT 2012

      I set up some aliases with IPv4 and IPv6 addresses, e.g. for some dual-stacked hosts.
      Now I would like to use such an alias to allow e.g. HTTP for IPv4 and IPv6 in one rule.
      But such a rule results in something like:
      pass in log quick on em0 reply-to (em0 129.x.y.z) inet proto tcp from <alias_1>to <alias_2>port = http flags S/SA keep state label "USER_RULE: allow HTTP"
      IPv4 traffic is ok, but IPv6 is not working, I think because of the "reply-to (em0 129.x.y.z).

      Is there a chance that in a future version of pfsense it will be possible to have one rule for dual-stacked aliases?</alias_2></alias_1>

      1 Reply Last reply Reply Quote 0
      • P
        podilarius last edited by

        First, I don't think you can combine IPV4 and IPV6 rules. You also cannot combine aliases. You will have to have one alias for IPv4 and another IPv6. You will also have to have 2 firewall rules as well.

        1 Reply Last reply Reply Quote 0
        • jimp
          jimp Rebel Alliance Developer Netgate last edited by

          Mixing in an alias is OK but you need two rules
          One for IPv4 and one for IPv6, both identical except for IPv4/6 selected.

          1 Reply Last reply Reply Quote 0
          • D
            databeestje last edited by

            Rules that apply to both address families are on the roadmap. There is just no ticket yet.

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

              It's good to know it is on the roadmap.

              And there is now also a ticket: http://redmine.pfsense.org/issues/2466

              1 Reply Last reply Reply Quote 0
              • D
                databeestje last edited by

                I just added that ticket and committed the code too. This is mainly for reference. Try and provide feedback.

                1 Reply Last reply Reply Quote 0
                • R
                  rcfa last edited by

                  @databeestje:

                  I just added that ticket and committed the code too. This is mainly for reference. Try and provide feedback.

                  I've added code that allows for setting a firewall rule to IPv4+IPv6

                  Limitations:

                  • only allows tcp/udp and icmp
                  • no icmp types
                  • no gateways or groups

                  Considering locking it down further to just rules with aliases.

                  Can you elaborate a bit on why the restrictions are there you listed? Just trying to understand the reasoning.

                  e.g. if I want the system to just act as a router, in IPv4-only, I just create a floating rule with allow any protocol from any address to any address on any interface. It would seem I can't do that specifying "any version of IP protocol", because that would run afoul of the "any protocol" part of the rule.

                  Are these IPv6/IPv4-combo rules broken into two rules behind the scenes, or do they remain one rule at the pf-level?

                  1 Reply Last reply Reply Quote 0
                  • D
                    databeestje last edited by

                    Yeah this is just 1 rule. These are not broken up into 2 rules, so I want to limit the choices

                    When we code support for splitting the rule behind the scenes some of the limitations may go.

                    I might actually add the any type. But I need to verify it doesn't cause rule errors before I do so.

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

                      @databeestje:

                      I just added that ticket and committed the code too. This is mainly for reference. Try and provide feedback.

                      Updated today to 2.1-BETA0 (amd64) built on Wed Jun 13 15:10:24 EDT 2012

                      On OPT-Interfaces dual-stack rules with dual-stack aliases are now working.
                      But as you have written in your comment to feature #2466 it is still not working on WAN-Interface rules.

                      What is the purpose of the "reply-to (wan-interface default-gw)" part of WAN-interface rules?

                      1 Reply Last reply Reply Quote 0
                      • jimp
                        jimp Rebel Alliance Developer Netgate last edited by

                        reply-to ensures that traffic goes back out the way it came in.

                        So in a multi-wan setup, if you query something (such as a port forward) that goes through to lan, when the return traffic goes back out, it would still leave via the wan it came in through. Otherwise it would consult the routing table and use the default gateway.

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

                          @jimp:

                          reply-to ensures that traffic goes back out the way it came in.

                          So in a multi-wan setup, if you query something (such as a port forward) that goes through to lan, when the return traffic goes back out, it would still leave via the wan it came in through. Otherwise it would consult the routing table and use the default gateway.

                          Thanks!

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

                          Products

                          • Platform Overview
                          • TNSR
                          • pfSense Plus
                          • 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