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



  • 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



  • 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).



  • 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



  • 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



  • 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.



  • 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.



  • 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.




  • 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



  • 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


Log in to reply