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

    Weird problem IPSEC

    IPsec
    3
    17
    4.6k
    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.
    • K
      kejianshi
      last edited by

      "Make sure you have the exact settings used in the example on this page:"
      http://doc.pfsense.org/index.php/Mobile_IPsec_on_2.0

      Then…

      "My config is a bit different"

      ;D

      Anyway - I've only ever gotten the config above to work.  Variations didn't go well for me.  (Its touchy even set up that way)

      Also, for me to get data to pass I always had to add forwarding route 0.0.0.0/0 on my client to get it to work - and a DNS server IP.

      1 Reply Last reply Reply Quote 0
      • P
        PDJ
        last edited by

        I can't change the config, because we won't get the security we want to have, but actually I think the setup is just fine and works (most of the time)
        It's just when I connect directly to the internet it won't work

        I can't post all the details, but the main settings are:
        Phase 1
        Authentication method: Mutual RSA + XAuth
        Negotiation mode: Main
        Policy Generation: Unique
        Proposal Checking: Obey
        Encryption algorithm: AES 256
        Hash algorith: SHA512

        Phase 2
        Encryption algorithms: AES 256
        Hash algorithms: SHA512

        I think it goes wrong somewhere in phase 2, but I don't know what it could be.

        1 Reply Last reply Reply Quote 0
        • K
          kejianshi
          last edited by

          Proposal Checking: Strict

          Why obey?

          1 Reply Last reply Reply Quote 0
          • K
            kejianshi
            last edited by

            As far as the AES 128/256 thing, I'd say there is no big difference.

            AES either has a back dor or it hasn't but both 128 and 256 have yet to be cracked.

            Anyway - looks like most of your settings are divergent from the manual - not just a few.

            1 Reply Last reply Reply Quote 0
            • P
              PDJ
              last edited by

              Ooh that's left of my trail and error, on Strict I've got the same result

              1 Reply Last reply Reply Quote 0
              • P
                PDJ
                last edited by

                Indeed, it's a bit different, I think the settings I have are a bit more secure.
                But it's working most of the time, so seems to me the settings are correct.

                Here is the log:
                Sep 6 15:32:28 racoon: [Self]: INFO: respond new phase 1 negotiation: ServerIP[500]<=>ClientIP[500]
                Sep 6 15:32:28 racoon: INFO: begin Identity Protection mode.
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: draft-ietf-ipsra-isakmp-xauth-06.txt
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-00
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-01
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-02
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: draft-ietf-ipsec-nat-t-ike-03
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: RFC 3947
                Sep 6 15:32:28 racoon: INFO: received broken Microsoft ID: FRAGMENTATION
                Sep 6 15:32:28 racoon: INFO: received Vendor ID: CISCO-UNITY
                Sep 6 15:32:28 racoon: [ClientIP] INFO: Selected NAT-T version: RFC 3947
                Sep 6 15:32:28 racoon: INFO: Adding xauth VID payload.
                Sep 6 15:32:28 racoon: [ClientIP] WARNING: CR received, ignore it. It should be in other exchange.
                Sep 6 15:32:28 racoon: [Self]: [ServerIP] INFO: Hashing ServerIP[500] with algo #6
                Sep 6 15:32:28 racoon: INFO: NAT-D payload #0 verified
                Sep 6 15:32:28 racoon: [ClientIP] INFO: Hashing ClientIP[500] with algo #6
                Sep 6 15:32:28 racoon: INFO: NAT-D payload #1 verified
                Sep 6 15:32:28 racoon: INFO: NAT not detected
                Sep 6 15:32:28 racoon: [ClientIP] INFO: Hashing ClientIP[500] with algo #6
                Sep 6 15:32:28 racoon: [Self]: [ServerIP] INFO: Hashing ServerIP[500] with algo #6
                Sep 6 15:32:28 racoon: INFO: Adding remote and local NAT-D payloads.
                Sep 6 15:32:28 racoon: WARNING: unable to get certificate CRL(3) at depth:0 <certificate details="">Sep 6 15:32:28 racoon: WARNING: unable to get certificate CRL(3) at depth:1 <certificate details="">Sep 6 15:32:28 racoon: INFO: Sending Xauth request
                Sep 6 15:32:28 racoon: [Self]: INFO: ISAKMP-SA established ServerIP[500]-ClientIP[500] spi:..
                Sep 6 15:32:28 racoon: [ClientIP] INFO: received INITIAL-CONTACT
                Sep 6 15:32:28 racoon: INFO: Using port 0
                Sep 6 15:32:28 racoon: user '<user>' authenticated
                Sep 6 15:32:28 racoon: INFO: login succeeded for user "<user>"
                Sep 6 15:32:28 racoon: WARNING: Ignored attribute INTERNAL_ADDRESS_EXPIRY
                Sep 6 15:32:34 racoon: [Self]: INFO: respond new phase 2 negotiation: ServerIP[500]<=>ClientIP[500]
                Sep 6 15:32:34 racoon: INFO: no policy found, try to generate the policy : 172.16.16.2/32[0] 192.168.32.0/19[0] proto=any dir=in
                Sep 6 15:32:34 racoon: [Self]: INFO: IPsec-SA established: ESP ServerIP[500]->ClientIP[500] spi=..
                Sep 6 15:32:34 racoon: [Self]: INFO: IPsec-SA established: ESP ServerIP[500]->ClientIP[500] spi=..
                Sep 6 15:32:43 racoon: ERROR: no configuration found for ClientIP.
                Sep 6 15:32:43 racoon: ERROR: failed to begin ipsec sa negotication.</user></user></certificate></certificate>

                1 Reply Last reply Reply Quote 0
                • K
                  kejianshi
                  last edited by

                  Are you sure this works anywhere?  Inside or outside the LAN?

                  I think you should just post your entire setup here and black out the public IP bits.

                  1 Reply Last reply Reply Quote 0
                  • P
                    PDJ
                    last edited by

                    What do you need to know, because I posted almost everything.
                    But I'm not allowed to post everything.

                    Only thing I didn't post is My identifier and Peer Identifier (but I tried different settings there, all gave the same result)
                    And I have NAT-T enabled, but when I dissable it it will give the same result
                    DPD dissabled (but enabled gave the same result either)
                    DH key group is set to 2

                    1 Reply Last reply Reply Quote 0
                    • K
                      kejianshi
                      last edited by

                      You can black out the juicy bits.  There will be no way to hack you with a blacked out configuration.

                      Or not - Its up to you.  Enjoy the VPN.

                      1 Reply Last reply Reply Quote 0
                      • P
                        PDJ
                        last edited by

                        Some additional information

                        I have a log from a connection from home (there it's working)
                        And the difference is

                        Working:

                        Aug 27 10:13:00 racoon: INFO: no policy found, try to generate the policy : 172.16.16.2/32[0] 192.168.32.0/19[0] proto=any dir=in
                        Aug 27 10:13:00 racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
                        Aug 27 10:13:00 racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)
                        Aug 27 10:13:00 racoon: [Self]: INFO: IPsec-SA established: ESP ServerIP[500]->ClientIP[500] spi=..

                        Not working:
                        Sep 6 15:32:34 racoon: INFO: no policy found, try to generate the policy : 172.16.16.2/32[0] 192.168.32.0/19[0] proto=any dir=in
                        Sep 6 15:32:34 racoon: [Self]: INFO: IPsec-SA established: ESP ServerIP[500]->ClientIP[500] spi=..

                        The part:
                        Aug 27 10:13:00 racoon: INFO: Adjusting my encmode UDP-Tunnel->Tunnel
                        Aug 27 10:13:00 racoon: INFO: Adjusting peer's encmode UDP-Tunnel(3)->Tunnel(1)

                        …is not in the log for a non working version

                        I hope this will give some information

                        I will try to make a more clear config, but unfortunately providing the complete config is prohibit by law in my case

                        1 Reply Last reply Reply Quote 0
                        • K
                          kejianshi
                          last edited by

                          See - I'm wondering if you shouldn't be using manual outbound NAT?  Just to test.

                          I'm wondering if port 500 is being handled as static port like it should be.

                          Seems like it POSSIBLY could be a NAT problem but its hard to work on a car when the guy he has a problem won't let you look under the hood.

                          1 Reply Last reply Reply Quote 0
                          • P
                            PDJ
                            last edited by

                            hmm NAT, yes I do use manual outbound NAT
                            At the moment I can't access the config, so I can't give you more details.
                            I'm sorry I can't provide you all the info… I can give you some details about the NAT (but that's a long list) where should I look for?

                            Maybe it has to do with the subnet, I have a small subnet on WAN, 2 addresses are assigned to both pfsense, 1 is the base CARP address and the rest of the IPs are aditional, the IPSEC is not running on the "base" address (not the default outbound adress) could that cause the problem?
                            And why does it work if the connections is coming from internet provider x,y and z and doesn't it work when the connection is from provider a,b and c

                            1 Reply Last reply Reply Quote 0
                            • K
                              kejianshi
                              last edited by

                              If you messed up the settings on the manual outbound NAT for port 500, that would do it.
                              You need to have a setting at the very top to pass port 500 as static port.  I had many subnets, so I put a rule in to pass a /16 as static on that port to take care of all the /24s.  That rule should have been autogenerated, but it would be very easy to mess it up or to put in a rule before it that breaks it.

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