Navigation

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

    parallel encrypted and unencrypted tunnels

    IPsec
    1
    2
    64
    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.
    • E
      Eric Scace last edited by

      Two types of traffic flow between two locations:
      • ordinary traffic that should be encrypted over the WANs
      • time-critical, low delay audio traffic that can be sent in the clear over the WANs.

      Both locations run Netgates with pfSense, and share a common 10.0.0.0/8 address space.

      Location A: 10.32.0.0/12, divided as follows

      • destinations that should receive their traffic encrypted: 10.32.0.0/13 (A-encrypt)
      • destinations that should receive their traffic clear: 10.40.0.0/13 (A-clear)

      Similarly, at location B: 10.160.0.0/12

      • 10.160.0.0/13 destinations receive encrypted traffic (B-encrypt)
      • 10.168.0.0/13 destinations receive clear traffic (B-clear)

      The attempted IPsec IKEv2-based solution:
      • Phase 1 IKEv2 with a pre-shared key for auth and encrypted phase 1 exchange.
      • four phase 2 child SAs:
      – A-encrypt to B-encrypt
      – A-clear to B-encrypt
      – A-encrypt to B-clear
      – A-clear to B-clear
      The last child uses AH only.

      This doesn't seem to work. Looking at the status/IPsec section seems to show that the subsequent tunnels get set up with aggregates of the address spaces from above, and the traffic doesn't flow, or doesn't flow as intended in the clear (AH-only) tunnel.

      Other attempts to aggregate addresses in the child definitions were similarly unsuccessful in exchanging traffic as well; e.g.,

      10.32.0.0 site:
      e1790864-24b8-425e-a569-ebea7b3db7e1-image.png

      10.160.0.0 site:
      c31bac9d-d3fa-49c8-9bd2-8f32c8d94d25-image.png

      resulted in the following when a device at 10.33.0.2 attempted to contact 10.160.0.1 and 10.169.1.1 in the far end encrypted and clear address ranges:
      45b72ad9-5a5f-490f-aaeb-eb21d3b45aea-image.png

      No response was obtained from the far end... and it appears all the address subnets were combined into a single tunnel with encrypted traffic.

      Similarly clear subnet to clear subnet communications did not occur.

      Suggestions?

      Do I need to create multiple phase 1 relationships between the same pair of sites to isolate the traffic flows into the correct type of tunnel?

      E 1 Reply Last reply Reply Quote 0
      • E
        Eric Scace @Eric Scace last edited by

        @eric-scace Last point: Everything works fine if there is only one Phase 2 definition for the full subnet at each site — except, of course, all traffic gets encrypted.

        Another way of looking at this problem: How does one take a tunnel between two sites that encrypts traffic (10.32.0.0/12 ↔︎ 10.160.0.0/12)... and divert traffic between a specific subset pair of address ranges (source & destination... in this example 10.40.0.0/13 ↔︎ 10.168.0.0/13) to be sent (potentially through a different tunnel) in the clear?

        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