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

    IPsec multiple Phase 2

    Scheduled Pinned Locked Moved IPsec
    4 Posts 2 Posters 362 Views 2 Watching
    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.
    • 0 Offline
      0x44
      last edited by

      Hi all,
      I have a newbie question about IPsec :). I have set up IPsec with EAP-MSCHAPv2 and multiple Phase 2 split tunneling with destinations.
      Tunel A - Client - Pfsense - 10.10.10.10
      Tunel B - Client - Pfsense - 10.10.11.10
      Is it possible to configure it so that, for instance, user A has access only to 10.10.10.10, and user B has access only to 10.10.11.10 or something similar to restrict access per user?
      Thanks for help.

      keyserK 1 Reply Last reply Reply Quote 0
      • keyserK Offline
        keyser Rebel Alliance @0x44
        last edited by

        @0x44 Yes, by not allowing the listed traffic in the firewall rules on the interface on which the clients exists. If you have a "any - any" rule there to allow full access to to internet (and in effect also everything else through VPN, the firewall itself and so on), create a block rule above that from the clients to the networks they are not allowed to reach.

        Love the no fuss of using the official appliances :-)

        0 1 Reply Last reply Reply Quote 0
        • 0 Offline
          0x44 @keyser
          last edited by

          @keyser I might not have expressed myself very clearly. But tunnels A and B share the same virtual IP pool, for example, 192.168.50.1/24, so the source IP address is the same for both tunnels.
          In this configuration, both clients have access to both networks — 10.10.10.10 and 10.10.11.10. That means, in order to restrict access from tunnel A to tunnel B (or vice versa), we would need to filter by source IP in the firewall. However, since the source is the same for both tunnels, this becomes problematic.
          Please correct me if I misunderstood your point or if I'm wrong about something.
          Below is an example of the allow rules I'm currently using.
          Firewall.png

          keyserK 1 Reply Last reply Reply Quote 0
          • keyserK Offline
            keyser Rebel Alliance @0x44
            last edited by keyser

            @0x44 I'm not quite sure I'm following your problem then.
            pfSense does not have a "layer 7" user concept on which you can create rules (rules against users/identities). It only does layer 2/3/4 (Ethernet/IP/Protocol) filtering.

            You mentioned virtual pool, is this because the users are also VPN clients, and you are looking to restrict to which S2S tunnel targets they are allowed to reach?

            Anyways, the only way you can restrict the access is by doing sourcefiltering in firewall rules, so you need a mechanism to make sure user A and user B always has IP addresses you know and can filter against. For regular LAN users this can be achieved by VLAN segmentation and different subnets if users A and B are each actually a large group of users. If it's just one user, you can do it by fx. DHCP reservation or use of static IPs on some clients. If they are VPN clients themselves, you need to use the "new" IP Pool feature and radius authentication of the VPN clients where you return the "Class" attribute from radius to assign which IP pool the client belongs to. If it's just two local VPN users on the firewall, you can assign their user a static VPN pool IP in the EAP-secret section, or by using Radius to return the framed-IP attribute.
            In all cases you can then filter access with source rules in the firewall rules.

            Love the no fuss of using the official appliances :-)

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