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

    IPSEC on Alix with PFsense 2.2

    IPsec
    5
    9
    2.0k
    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.
    • F
      fs
      last edited by

      Hello together,

      just registered here to report some potential bug.

      I recently updated to pfsense 2.2 and found the IPSEC-Tunnel not running (no it didn't run before, because something wasn't configured correctly and I didn't had time to follow this up.

      I digged somehow deeper and found the following log:
      "[IKE] unable to install inbound and outbound IPsec SA (SAD) in kernel".

      While searching through the I-Net I didn't found a clear answer on my problem so I report it here.

      I switched back to 2.1.5 and there the IPSEC-Tunnel was coming up fine immediately … with the config done in 2.2 ... congrats on this.

      The affected system is an ALIX board with nanobsd install while on the APU with standard install the IPSEC-Tunnel is running fine.

      Here I decided to leave this issue up to the professionals ...

      Regards

      FS

      1 Reply Last reply Reply Quote 0
      • C
        Clouseau
        last edited by

        I use Alix boards 2D3 and APU with no issues (site-to-site vpn IKEv1 and IKEv2.)  It would help that you would show your Phase1&2 config.

        –--------------------------------------------------------------
        Multible Alix 2D13, APU1,APU2,APU3 - pfSense 2.4.x 64bit
        Multible Vmware vSphere - pfSense 2.4.x 64bit

        pfSense - FreeNAS - OwnCloud

        1 Reply Last reply Reply Quote 0
        • F
          fs
          last edited by

          I think I got it fixed … it's been the glxsb restriction of aes to 128bit keylength ...

          Interestingly the 2.1.5 obviously has chosen at least once the 128bit keylength even though it was set to automatic. I couldn't reproduce it ... but I don't care abaut that.

          Now both boxes are running on 2.2 with the tunnel up ...

          Thanks anyway, thread can be closed.

          FS

          1 Reply Last reply Reply Quote 0
          • A
            AndrewZ
            last edited by

            Just faced the same issue while configuring IKEv2 remote access between Android (strongSwan VPN Client) and PFsense 2.2 on my Alix 2D13.
            Change from AES-256 to AES-128 solved the issue.

            BTW, is it really necessary to manually add rules for UDP 500 and 4500 on WAN? Someone mentioned that those rules added automatically.

            1 Reply Last reply Reply Quote 0
            • C
              cmb
              last edited by

              I added input validation to prevent attempting to use AES > 128 bit where glxsb is enabled, as people don't seem to realize that card will break > 128 bit.
              https://redmine.pfsense.org/issues/4361

              I also added a note to the upgrade guide, since this misconfiguration apparently wasn't a problem previously, but strongswan (rightly) uses the strongest-available key length, which glxsb breaks.
              https://doc.pfsense.org/index.php/Upgrade_Guide#IPsec_Changes

              @AndrewZ:

              BTW, is it really necessary to manually add rules for UDP 500 and 4500 on WAN? Someone mentioned that those rules added automatically.

              No, those are automatically added.

              1 Reply Last reply Reply Quote 0
              • A
                AndrewZ
                last edited by

                @cmb:

                No, those are automatically added.

                Thanks, but I don't think it's the case on my box. I had to add the rules manually when I noticed the ports blocked in the firewall log.
                What will be the right way to check this behavior? Remove all IPSec configs, reboot and add again?

                1 Reply Last reply Reply Quote 0
                • D
                  doktornotor Banned
                  last edited by 

                  
pfctl -sa | egrep "isakmp|nat-t|esp" | grep pass
                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    It'll add them to the interface where it's bound. There are some exceptions where you have to manually add rules, like if you have a routed public IP subnet with VIPs on an interface other than the WAN where those are sourced, there is no way to tell definitively where that traffic will be coming from, so manual rules are required in that circumstance. For all the most common circumstances, where you're binding to WAN or a VIP on WAN, they're there automatically.

                    1 Reply Last reply Reply Quote 0
                    • A
                      AndrewZ
                      last edited by

                      OK, removed manual routes I added, disabled IPSec, rebooted, re-enabled IPSec - routes are there:

                      /root: pfctl -sa | egrep "isakmp|nat-t|esp" | grep pass
pass out proto udp from any to any port = isakmp keep state label "IPsec:  any  - outbound isakmp"
pass in on vr1 proto udp from any to any port = isakmp keep state label "IPsec:  any  - inbound isakmp"
pass out proto udp from any to any port = sae-urn keep state label "IPsec:  any  - outbound nat-t"
pass in on vr1 proto udp from any to any port = sae-urn keep state label "IPsec:  any  - inbound nat-t"
pass out proto esp all keep state label "IPsec:  any  - outbound esp proto"
pass in on vr1 proto esp all keep state label "IPsec:  any  - inbound esp proto"

                      Thanks!

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