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

    AWS PfSense Plus Site to Site IPSEC

    Scheduled Pinned Locked Moved General pfSense Questions
    7 Posts 2 Posters 1.1k Views
    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.
    • P
      Paddy
      last edited by

      I have used PfSense for a while now. During this time I have setup many IPSEC tunnels.

      I have now been tasked with setting up similar within AWS.

      I have installed PfSense with a WAN and LAN and setup OpenVPN for our users.

      I have created a transit gateway in AWS and have a IPSEC tunnel from the PfSense instance to this transit gateway.

      As it stands I can connect to open vpn and reach the LAN side and all our VPCs.

      My next step is to add some IPSEC tunnels to some external 3rd parties. This is where I am failing miserably.

      As a test I tried to create a IPSEC tunnel between our on premise PfSense box to the AWS PfSense instance.
      The tunnel just sits at 'connecting' before giving up.

      Can someone advise where to look.

      Thanks,
      Paddy

      All I see in the log is;

      Dec 14 10:43:12	charon	71240	07[MGR] <con500000|45200> checkin of IKE_SA successful
Dec 14 10:43:12	charon	71240	07[MGR] <con500000|45200> checkin IKE_SA con500000[45200]
Dec 14 10:43:12	charon	71240	07[NET] <con500000|45200> sending packet: from 217.xxx.xxx.xxx[500] to 52.xxx.xxx.xx[500] (464 bytes)
Dec 14 10:43:12	charon	71240	07[ENC] <con500000|45200> generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> IKE_SA con500000[45200] state change: CREATED => CONNECTING
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> initiating IKE_SA con500000[45200] to 52.xxx.xxx.xxx
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_AUTH_LIFETIME task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating CHILD_CREATE task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_CONFIG task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_CERT_POST task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_AUTH task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_CERT_PRE task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_NATD task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_INIT task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating IKE_VENDOR task
Dec 14 10:43:12	charon	71240	07[IKE] <con500000|45200> activating new tasks
      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        That's at the on premise side I assume since it has a public IP?

        What does the log at the other side show?

        Do you see states from the remote side IP in the AWS side state table?

        Blocks in the firewall log?

        Try running a pcap at the AWS side for the port 500 traffic from the remote public IP. Is the traffic arriving at all?

        As long as AWS is passing the traffic there should be nothing special required here.

        Steve

        P 1 Reply Last reply Reply Quote 0
        • P
          Paddy @stephenw10
          last edited by

          @stephenw10 said in AWS PfSense Plus Site to Site IPSEC:

          Try running a pcap at the AWS side for the port 500 traffic from the remote public IP. Is the traffic arriving at all?
          As long as AWS is passing the traffic there should be nothing special required here.

          That was the problem. A capture showed no traffic hitting port 500. I thought I had changed the AWS security group to allow all from all but I hadn't. Once I added a inbound udp 500 from all it sprang into life.

          As a side question - should the AWS security group mirror the PfSense rules or should I just go with an 'allow all from all' on the security group?

          Thanks again for you time pointing me in the right direction.

          1 Reply Last reply Reply Quote 0
          • stephenw10S
            stephenw10 Netgate Administrator
            last edited by

            It could be either but it's best practice to only allow the traffic you need.

            With a site to site tunnel like that it would usually be able to establish either way which means you often don't actually need a rule for port 500. It's better to have one so that it can establish from both ends though. It does imply that the P2 at the AWS end probably doesn't have a ping-host target set or it would have tried to come up before you added the rule.

            Steve

            P 1 Reply Last reply Reply Quote 0
            • P
              Paddy @stephenw10
              last edited by

              @stephenw10

              Hi Stephen,

              I'm still having problems with my site to site IPSEC VPN.

              It's between a onsite pfsense box and a AWS pfSense+

              I can't get the tunnel to connect. The AWS pfSense+ instance has a elastic IP assigned to it's WAN interface. This IP is 52.xxx.xxx.19 it also has a private wan IP of 10.xxx.xxx.107.

              When I look at the status of the IPSEC connection it says it has a ID of 52.xxx.xxx.19 and a host of 10.xxx.xxx.107

              The IPSEC log is below. I think it's because the host IP it is sending is the private IP and not the elastic IP but I'm not sure how to sort.
              Everything else works. I have a VPN to a transit gateway. Hosts on the AWS LAN can connect out and use the elastic IP. OpenVPN clients work and also show the elastic IP on whatsmyip.

              Any ideas how to solve?

              Thanks,
              Paddy

              Jan 11 23:02:39	charon	70975	07[NET] <23> received packet: from 217.xxx.xxx.150[500] to 10.xxx.xxx.107[500] (464 bytes)
Jan 11 23:02:39	charon	70975	07[ENC] <23> parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
Jan 11 23:02:39	charon	70975	07[CFG] <23> looking for an IKEv2 config for 10.xxx.xxx.107...217.xxx.xxx.150
Jan 11 23:02:39	charon	70975	07[CFG] <23> candidate: 10.xxx.xxx.107...217.xxx.xxx.150, prio 3100
Jan 11 23:02:39	charon	70975	07[CFG] <23> found matching ike config: 10.xxx.xxx.107...217.xxx.xxx.150 with prio 3100
Jan 11 23:02:39	charon	70975	07[IKE] <23> 217.xxx.xxx.150 is initiating an IKE_SA
Jan 11 23:02:39	charon	70975	07[IKE] <23> IKE_SA (unnamed)[23] state change: CREATED => CONNECTING
Jan 11 23:02:39	charon	70975	07[CFG] <23> selecting proposal:
Jan 11 23:02:39	charon	70975	07[CFG] <23> proposal matches
Jan 11 23:02:39	charon	70975	07[CFG] <23> received proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Jan 11 23:02:39	charon	70975	07[CFG] <23> configured proposals: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Jan 11 23:02:39	charon	70975	07[CFG] <23> selected proposal: IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
Jan 11 23:02:39	charon	70975	07[CFG] <23> received supported signature hash algorithms: sha256 sha384 sha512 identity
Jan 11 23:02:39	charon	70975	07[IKE] <23> local host is behind NAT, sending keep alives
Jan 11 23:02:39	charon	70975	07[CFG] <23> sending supported signature hash algorithms: sha256 sha384 sha512 identity
Jan 11 23:02:39	charon	70975	07[ENC] <23> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
Jan 11 23:02:39	charon	70975	07[NET] <23> sending packet: from 10.xxx.xxx.107[500] to 217.xxx.xxx.150[500] (472 bytes)
Jan 11 23:02:45	charon	70975	15[CFG] vici client 317 connected
Jan 11 23:02:45	charon	70975	15[CFG] vici client 317 registered for: list-sa
Jan 11 23:02:45	charon	70975	14[CFG] vici client 317 requests: list-sas
Jan 11 23:02:45	charon	70975	13[CFG] vici client 317 disconnected
Jan 11 23:02:51	charon	70975	12[CFG] vici client 318 connected
Jan 11 23:02:51	charon	70975	12[CFG] vici client 318 registered for: list-sa
Jan 11 23:02:51	charon	70975	08[CFG] vici client 318 requests: list-sas
Jan 11 23:02:51	charon	70975	12[CFG] vici client 318 disconnected
Jan 11 23:02:57	charon	70975	13[CFG] vici client 319 connected
Jan 11 23:02:57	charon	70975	13[CFG] vici client 319 registered for: list-sa
Jan 11 23:02:57	charon	70975	13[CFG] vici client 319 requests: list-sas
Jan 11 23:02:57	charon	70975	14[CFG] vici client 319 disconnected
Jan 11 23:02:59	charon	70975	11[IKE] <23> sending keep alive to 217.xxx.xxx.150[500]
Jan 11 23:03:03	charon	70975	12[CFG] vici client 320 connected
Jan 11 23:03:03	charon	70975	12[CFG] vici client 320 registered for: list-sa
Jan 11 23:03:03	charon	70975	12[CFG] vici client 320 requests: list-sas
Jan 11 23:03:03	charon	70975	08[CFG] vici client 320 disconnected
Jan 11 23:03:09	charon	70975	14[CFG] vici client 321 connected
Jan 11 23:03:09	charon	70975	14[CFG] vici client 321 registered for: list-sa
Jan 11 23:03:09	charon	70975	13[CFG] vici client 321 requests: list-sas
Jan 11 23:03:09	charon	70975	13[CFG] vici client 321 disconnected
Jan 11 23:03:09	charon	70975	16[JOB] <23> deleting half open IKE_SA with 217.xxx.xxx.150 after timeout
Jan 11 23:03:09	charon	70975	16[IKE] <23> IKE_SA (unnamed)[23] state change: CONNECTING => DESTROYING
              stephenw10S 1 Reply Last reply Reply Quote 0
              • stephenw10S
                stephenw10 Netgate Administrator @Paddy
                last edited by

                @paddy said in AWS PfSense Plus Site to Site IPSEC:

                I think it's because the host IP it is sending is the private IP and not the elastic IP

                Yup that's probably true. The logs from the other side would show it being refused if so.

                You just need the identifiers to match so you can change either end.

                At the AWS end you would change the identifier from 'My IP Address' to 'IP Address' and then set the external IP.

                Steve

                P 1 Reply Last reply Reply Quote 0
                • P
                  Paddy @stephenw10
                  last edited by

                  @stephenw10

                  Hi Stephen,

                  I did have 'my identifier' set to the address with the elastic IP set. I finally found the problem. The inbound rules on the office pfSense did not allow udp/4500. Once I added a allow for the source IP the connection came up instantly.

                  Thanks again,
                  Paddy

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