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

    IPSEC rules as floating not working

    Scheduled Pinned Locked Moved Firewalling
    6 Posts 2 Posters 713 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.
    • junicastJ
      junicast
      last edited by junicast

      Hi,

      pfSense 2.4.4p3 CARP with two dedicated X86 systems.

      I have an IPSEC Tunnel to a remote destination.
      Our users come in locally via LAN interface but there are also OpenVPN roadwarrios. Both type of clients shall get the same set of rules which is why I use floating rules where I select both the LAN and the OpenVPN interface for the rules. That way I can keep the rules in sync to each other. Reasonable, right?
      There is one rule that is for connections to a remote site that is connected via IPSEC. The IPSEC connections is using (S)NAT though, meaning I created two phase 2 entries in the IPSEC tunnel, one for each interface.
      Those floating rules don't work though.
      If I specify one rule in the LAN interface and one in the OpenVPN interface seperately they work.
      What can I do to make them work in floating or isn't that possible with IPSEC connections?

      interface rule:
      ipsec_interface_rule.png

      floating rule (there are actually two interfaces selected but can't grow the selection box)
      ipsec_floating.png

      1 Reply Last reply Reply Quote 0
      • junicastJ
        junicast
        last edited by

        What I was lacking was the Quick flag on the floating rule because within the non-floating rules of the interface there's a REJECT rule.
        Without that Quick flag it's Last Fit not First Fit.

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

          I am going to expand on that a little.

          As the rule set is processed, rules without quick set determine what happens to a packet when the end of the rule set is reached. Packets can be matched by multiple non-quick rules that can change the action to be taken as the rule set is processed.

          There can also be match rules that set certain characteristics (like a pipe or shaping queue or packet tag) and processing always continues through the rule set because they neither block nor pass traffic. Match rules always behave like non-quick rules.

          Processing stops and the matching action is taken when a rule matches with quick set.

          This is how the default deny rule works. It is very high in the rule set and sets all traffic on all interfaces to deny but is not quick. So if nothing further down changes that (like a matching pass rule) that is the action taken on the packet when the end of the rule set is reached.

          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)

          junicastJ 1 Reply Last reply Reply Quote 0
          • junicastJ
            junicast @Derelict
            last edited by

            @Derelict
            Thank you for that good explanation.
            I think for my purpose it would be better to create Interface Groups because all I want is to keep rules for different interfaces in sync to each other.

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

              Interface groups are great if the rule set can be crafted so it applies properly to all interfaces in the group. There is usually some difference in rule sets on each interface, however.

              I use an interface group to block egress of anything RFC1918 out the WANS group, for instance. (Or ULA on IPV6WANS, etc)

              Another application I have seen is setting each interface's DHCP server to set the same DNS server (not the interface address) and you can then make an interface group rule that passes DNS to that server.

              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 1
              • junicastJ
                junicast
                last edited by

                In my case we have users who work remotely via VPN who whall get the same filters as those who work locally.

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