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

    IPSec not working after Update to 1.2-BETA-1-TESTING-SNAPSHOT-06-04-2007

    IPsec
    3
    9
    3.8k
    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.
    • M
      morbus
      last edited by

      IPSec seems to have stopped working after upgrading to 1.2-BETA-1-TESTING-SNAPSHOT-06-04-2007 from a 1.0.1 snapshot (cant remember which one)

      I have a CARP setup and had the 1.0.1 setup to use the CARP VIP in the "failover IP" setting but this seems to be missing on 1.2

      I haven't made any other changes to the setup. The logs suggest it is trying phase 1 but then timing out waiting.
      Is this because it is still listening on the masters normal IP as if I change the remote end to look to the master direct rather than the CARP VIP it comes up fine

      Ps otherwise 1.2 is looking great and I love the 1.3 dashboard package very cool. The big vendors could learn a thing or two from you guys ;D

      1 Reply Last reply Reply Quote 0
      • S
        sullrich
        last edited by

        Visit the IPSEC settings for each tunnel and select the CARP interface on the Interface dropdown menu item.  We removed failover IP and now you can select the CARP interfaces directly (Think multi-wan CARP ISP goodness).

        1 Reply Last reply Reply Quote 0
        • M
          morbus
          last edited by

          D'oh should of spotted that  ::)

          That method is much simpler you should get less people not understanding how to use the failover settings now

          Thanks

          1 Reply Last reply Reply Quote 0
          • M
            morbus
            last edited by

            Well that almost fixed it.

            Now the tunnel will come up fine from the carp end and works fine and if the tunnel is open the remote site works fine
            but when opening the tunnel from the remote site it won't open up.
            If I make the tunnel ends bind directly to the master then the tunnels work fine.
            It is just to the carp address that fails.

            The remote site runs PFsense 1.01 embedded on a standard PC from a CF card

            1 Reply Last reply Reply Quote 0
            • S
              sullrich
              last edited by

              I am using this option fine in many locations with 0 problems.  Please ensure your configuration is correct on the other end of the tunnel.

              1 Reply Last reply Reply Quote 0
              • M
                morbus
                last edited by

                I have been over the config on both ends of the tunnel and it looks fine to me.

                The tunnel will work if I open it from the carp end (in both directions ie either end can ping the other) and if I bind it to the master it will open at either end and it was working fine in all directions before going to 1.2.

                after a time of no activity on the carp end the tunnel will shutdown if it is only being pinged from the the non carp end

                when the non carp end is trying to open the tunnel I get this in the logs

                Jun 8 14:14:51 racoon: INFO: delete phase 2 handler.
                Jun 8 14:14:51 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP x.y.z.120[500]->a.b.c.42[500]
                Jun 8 14:14:42 racoon: INFO: delete phase 2 handler.
                Jun 8 14:14:42 racoon: ERROR: phase2 negotiation failed due to time up waiting for phase1. ESP x.y.z.120[500]->a.b.c.42[500]
                Jun 8 14:14:41 racoon: INFO: begin Aggressive mode.
                Jun 8 14:14:41 racoon: INFO: initiate new phase 1 negotiation: a.b.c.42[500]<=>z.y.z.120[500]

                there are no log messages on the other end all the time this is going on

                the carp VIP is x.y.z.120
                the cluster have physical IPs x.y.z.118 (master) and x.y.z.119 (slave)
                a.b.c.42 is the other end

                this is the messages from the carp end when saving the ipsec config

                Jun 8 13:26:25 racoon: INFO: x.y.z.118[500] used as isakmp port (fd=24)
                Jun 8 13:26:25 racoon: INFO: fe80::204:76ff:fea1:7609%xl0[500] used as isakmp port (fd=23)
                Jun 8 13:26:25 racoon: INFO: 192.168.2.1[500] used as isakmp port (fd=22)
                Jun 8 13:26:25 racoon: INFO: fe80::201:3ff:febb:494e%xl1[500] used as isakmp port (fd=21)
                Jun 8 13:26:25 racoon: INFO: 10.0.0.1[500] used as isakmp port (fd=20)
                Jun 8 13:26:25 racoon: INFO: fe80::201:2ff:fee3:2ea5%xl4[500] used as isakmp port (fd=19)
                Jun 8 13:26:25 racoon: INFO: 127.0.0.1[500] used as isakmp port (fd=18)
                Jun 8 13:26:25 racoon: INFO: ::1[500] used as isakmp port (fd=17)
                Jun 8 13:26:25 racoon: INFO: fe80::1%lo0[500] used as isakmp port (fd=16)
                Jun 8 13:26:25 racoon: INFO: 192.168.2.3[500] used as isakmp port (fd=15)
                Jun 8 13:26:25 racoon: INFO: x.y.z.120[500] used as isakmp port (fd=14)
                Jun 8 13:26:25 racoon: INFO: unsupported PF_KEY message REGISTER

                Is there anything that I should look for that may cause this behaviour??

                Thanks.

                1 Reply Last reply Reply Quote 0
                • M
                  morbus
                  last edited by

                  Well I have tracked down the bug/feature. It looks as if the firewall is blocking (well not explicitly allowing) the esp proto from the carp address in the SPD'd

                  These are the rules created by the pfsense on its own

                  pass out quick on xl0 inet proto udp from x.y.z.118 to a.b.c.42 port = isakmp keep state label "IPSEC: Tunnel to home - outbound isakmp"
                  pass out quick on carp1 inet proto udp from x.y.z.118 to a.b.c.42 port = isakmp keep state label "IPSEC: Tunnel to home - outbound isakmp"
                  pass in quick on xl0 inet proto udp from a.b.c.42 to x.y.z.118 port = isakmp keep state label "IPSEC: Tunnel to home - inbound isakmp"
                  pass in quick on carp1 inet proto udp from a.b.c.42 to x.y.z.118 port = isakmp keep state label "IPSEC: Tunnel to home - inbound isakmp"
                  pass out quick on xl0 inet proto esp from x.y.z.118 to a.b.c.42 keep state label "IPSEC: Tunnel to home - outbound esp proto"
                  pass out quick on carp1 inet proto esp from x.y.z.118 to a.b.c.42 keep state label "IPSEC: Tunnel to home - outbound esp proto"
                  pass in quick on xl0 inet proto esp from a.b.c.42 to x.y.z.118 keep state label "IPSEC: Tunnel to home - inbound esp proto"
                  pass in quick on carp1 inet proto esp from a.b.c.42 to x.y.z.118 keep state label "IPSEC: Tunnel to home - inbound esp proto"

                  Notice these are all pointing to 118 which is the master rather than 120 which is the CARP address

                  If I add the following it all works fine

                  pass in quick on xl0 inet proto esp from a.b.c.42 to x.y.z.120 keep state label "USER_RULE: Allow IPSEC access from Home"
                  pass in quick on carp1 inet proto esp from a.b.c.42 to x.y.z.120 keep state label "USER_RULE: Allow IPSEC access from Home"

                  and I have attached a picture of my ipsec setup so you can be sure I am using the correct interface

                  I am guessing it is supposed to add the SPD rule based on the address of the interface in use or is this a deliberate feature??

                  Thanks.

                  ipsec.JPG
                  ipsec.JPG_thumb

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

                    That's actually a design decision that was consciously made, though it's inconsistent and needs to be fixed, IMO. We hide the rules allowing IPsec traffic to your WAN IP, and don't create rules for CARP IP's.

                    I opened a ticket on it.
                    http://cvstrac.pfsense.org/tktview?tn=1349

                    1 Reply Last reply Reply Quote 0
                    • M
                      morbus
                      last edited by

                      Thanks for that. I have to say I agree that hidden rules are bad. Maybe you could do the same as with NAT and auto create a rule if the check box is checked.

                      Either way it needs to be consistent between creating a rule for a carp and a wan. Especially given that the carp address/interface is now selected from the same dropdown as the WAN interface

                      Thanks for a great firewall

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