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

    IPSEC Site To Site

    IPsec
    2
    9
    569
    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.
    • S
      SavvyGolfer
      last edited by

      Hello everyone, we are new to the Netgate Community

      Anyone got any ideas on this?

      We are trying to connect a VPN tunnel from a Cisco RV042 router to a Netgate XG-7100 Router. Every time we try to make the connection the XG-7100 says that there is a missing DH Group proposal even though we have it configured properly on the XG-7100.

      Here are some of the Logs:

      Aug 5 16:12:36 charon 08[IKE] <9> is initiating a Main Mode IKE_SA
      Aug 5 16:12:36 charon 08[IKE] <9> IKE_SA (unnamed)[9] state change: CREATED => CONNECTING
      Aug 5 16:12:36 charon 08[CFG] <9> selecting proposal:
      Aug 5 16:12:36 charon 08[CFG] <9> no acceptable DIFFIE_HELLMAN_GROUP found
      Aug 5 16:12:36 charon 08[CFG] <9> selecting proposal:
      Aug 5 16:12:36 charon 08[CFG] <9> no acceptable ENCRYPTION_ALGORITHM found
      Aug 5 16:12:36 charon 08[CFG] <9> received proposals: IKE:AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1536
      Aug 5 16:12:36 charon 08[CFG] <9> configured proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048
      Aug 5 16:12:36 charon 08[IKE] <9> no proposal found
      Aug 5 16:12:36 charon 08[IKE] <9> queueing INFORMATIONAL task
      Aug 5 16:12:36 charon 08[IKE] <9> activating new tasks
      Aug 5 16:12:36 charon 08[IKE] <9> activating INFORMATIONAL task
      Aug 5 16:12:36 charon 08[ENC] <9> generating INFORMATIONAL_V1 request 1058529224 [ N(NO_PROP) ]
      Aug 5 16:12:36 charon 08[NET] <9> sending packet: from XXX.XXX.XXX.XXX[500] to XXX.XXX.XXX.XXX[500] (56 bytes)
      Aug 5 16:12:36 charon 08[IKE] <9> IKE_SA (unnamed)[9] state change: CONNECTING => DESTROYING
      Aug 5 16:12:36 charon 08[NET] <con2000|8> received packet: from [500] to XXX.XXX.XXX.XXX[500] (56 bytes)
      Aug 5 16:12:36 charon 08[ENC] <con2000|8> parsed INFORMATIONAL_V1 request 1058529224 [ N(NO_PROP) ]
      Aug 5 16:12:36 charon 08[IKE] <con2000|8> received NO_PROPOSAL_CHOSEN error notify
      Aug 5 16:12:36 charon 08[IKE] <con2000|8> IKE_SA con2000[8] state change: CONNECTING => DESTROYING

      What we are seeing that there is no MODP_1536 which is DH Group 5. Unfortunately the Cisco RV042 only uses DH Groups 1, 2, and 5. And from what you can see in the logs above, MODP_1536 doesn't show up in the configured proposals list.

      We also have a second XG-7100 for our data center and the IPsec VPN works fine on that one and the list of configured proposals shows MODP_1536. So two identical routers and one is working properly with the IPsec VPN and the other isn't. They both have the same current pfSenseSystem Versions 2.4.4_3

      Here's a screenshot of our XG-7100 Config.

      VPN Config.png

      Anyone ever seen this type of behavior before?

      Thanks and if you need more info from us, just let us know.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        Yeah. it is probably not matching the Phase 1 for some reason so it is not using your selected proposals for that connection.

        Post everything from the first packet received.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

          Derelict thanks for the fast response.

          Since we are so new to pfSense and Netgate, what is the best way to do this? Logs from the XG-7100 or do we need to use wireshark on the PC we are trying to initiate the tunnel on the Cisco router? We are using a laptop connected to the Cisco router to log into the router and then try to initiate the VPN tunnel to the XG-7100 that is giving us the problem.

          Thanks,

          -Jeff

          1 Reply Last reply Reply Quote 0
          • DerelictD
            Derelict LAYER 8 Netgate
            last edited by

            Complete logs is what I was talking about.

            Chattanooga, Tennessee, USA
            A comprehensive network diagram is worth 10,000 words and 15 conference calls.
            DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
            Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

              Derelict, again thanks for helping out here.

              I actually just figured it out about 30 mins ago and I think I've solved the issue. And being new to the pfSense software it ended up being a configuration issue due to some of the testing we have been going through with these units over the past couple of weeks. So I finally tracked down the config differences between the two routers and had that aha moment. Changed/removed the configs on the router that was acting up and the tunnel connected no problem.

              Long story short is that we had set up some test virtual IP's on the one XG-7100 router and the Cisco router that we were using to test theses IPsec tunnels is set up using the same WAN IP as we had set up as a virtual IP on the one XG-7100 that was giving us the issue. So I removed the virtual IP and there you go, the tunnel connects fine. So I think we should be good to go, (hopefully).

              Thanks again for the quick responses!

              -Jeff

              1 Reply Last reply Reply Quote 0
              • DerelictD
                Derelict LAYER 8 Netgate
                last edited by

                Virtual IP should not matter unless the IPsec was set to use it.

                In any case glad you found it.

                Chattanooga, Tennessee, USA
                A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                Do Not Chat For Help! NO_WAN_EGRESS(TM)

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

                  Ok, thanks for the info and we will keep that in mind. Being so new to pfSense, we have a long learning curve ahead of us.

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

                    Don't know if I should ask this here or not since this is resolved, but in pfSense with point to point IPsec tunnels, will they come back up automatically after a reboot or something like that, or do you have to go in and manually initiate the connection again?

                    1 Reply Last reply Reply Quote 0
                    • DerelictD
                      Derelict LAYER 8 Netgate
                      last edited by

                      Each side should initiate when there is traffic matching the traffic selector.

                      In many cases you can make this happen by setting an automatically ping host to something on the other side in each P2. (it just has to match the remote network - it doesn't actually have to respond to ping).

                      Tunnels generally come up very quickly and the fact that the tunnel was not actually up when the traffic is initiated is not noticed by users or applications.

                      Chattanooga, Tennessee, USA
                      A comprehensive network diagram is worth 10,000 words and 15 conference calls.
                      DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
                      Do Not Chat For Help! NO_WAN_EGRESS(TM)

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