Hi, Ok working well now, actually I shouldn't have set up the srcid with my public_ip. Without this line (or this line containing private IP) it's working well.
Regards, Sebastien On Sat, Mar 18, 2017 at 2:03 AM, Sébastien Morand <[email protected]> wrote: > Hello Mike, > > "group none" in phase 2 because of this in the documentation: > << > Possible values for auth, enc, and group are described below in CRYPTO > TRANSFORMS. Perfect Forward Secrecy (PFS) is enabled unless group none is > specified. > >> > > And their documentation says: No PFS. As far as I understand I disable PFS > by putting "group none" in phase 2, don't I? > > I'm actually waiting their logs for more information. > > Regards, > Sebastien > > > On Thu, Mar 16, 2017 at 10:08 PM, Mik J <[email protected]> wrote: > >> Hello Sebastien, >> Why "group none" for phase 2 ? >> >> " The following group types are permitted with the group keyword: >> Group Size >> none 0 [phase 2 only] >> " >> >> maybe you should ask them their conf and their logs >> >> Try also >> sysctl -a | grep esp >> >> >> >> >> Le Jeudi 16 mars 2017 16h33, Sébastien Morand <[email protected]> a >> écrit : >> >> >> Hi Mike and everybody, >> >> Thank you Mike for your answer. There is nothing more like you said. >> Actually we succeed in phase 1 but not in phase 2. >> >> My client give me the following spec: >> Phase 1: SHA1 - 160 bits / DH 5 / Authentication with PSK / CIPHER : >> AES-256 / Lifetime 86400s >> Phase 2: Tunnel mode / SHA1 / No PFS / Authentication with PSK / CIPHER >> AES-128 / Lifetime 3600s >> >> So I end up with the following in ipsec.conf: >> ike active esp tunnel \ >> from 10.85.98.16/29 to \ >> {10.249.0.0/21} \ >> peer <public_ip_of_my_client> \ >> main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \ >> quick auth hmac-sha1 enc aes-128 group none lifetime 3600 \ >> srcid "<my_public_ip>" \ >> psk "************" >> >> I'm starting the ipsec like this : >> isakmpd -Kdvvv (to see what is happening) >> and >> ipsecctl -f /etc/ipsec.conf >> >> It's look like good to me and conform to the provided specs. Phase 1 is ok >> but no phase 2: >> 155851.640374 Default ipsec_validate_id_information: dubious ID >> information >> accepted >> 155851.640478 Default isakmpd: phase 1 done: initiator id 196.207.241.154, >> responder id 80.125.165.142, src: 192.168.254.2 dst: 80.125.165.142 >> 155918.682560 Default transport_send_messages: giving up on exchange >> from-10.85.98.16/29-to-10.249.0.0/21, no response from peer >> 80.125.165.142:4500 >> 155918.682611 Default transport_send_messages: giving up on exchange >> from-10.85.98.16/29-to-80.125.172.0/23, no response from peer >> 80.125.165.142:4500 >> 155918.682644 Default transport_send_messages: giving up on exchange >> from-10.85.98.16/29-to-80.125.174.0/24, no response from peer >> 80.125.165.142:4500 >> >> In TCPDUMP I got no answer on port 4500 (but everything fine on port 500) >> so it means to me they don't answer to my packet but I don't know why : >> 16:01:41.673599 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:01:41.673655 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:01:41.673674 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:01:50.686803 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:01:50.686862 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:01:50.686881 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:02:01.700016 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:02:01.700106 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> 16:02:01.700154 192.168.254.2.4500 > 80.125.165.142.4500:udpencap: isakmp >> v1.0 exchange QUICK_MODE encrypted >> (... it can last forever ...) >> >> Any idea what can be done or a way to get more information on what's going >> on? They are using CISCO 6509 with IOS 12.2-33.SXH3a. >> >> Thanks by advance, >> Sebastien >> >> On Tue, Mar 14, 2017 at 12:46 AM, Mik J <[email protected]> wrote: >> >> > Hello Sebastien, >> > I'm not sure there's something special to force nat-t, it's automatic. >> > The natted side has to initiate the flow to the non natted side. >> > If the two sides are natted then there should be a port forward to one >> of >> > them. >> > There should be a nat keepalive parameter as well. >> > >> > >> > >> > Le Lundi 13 mars 2017 18h40, Sébastien Morand <[email protected]> a >> > écrit : >> >> > >> > >> > Hi, >> > >> > I'm trying to set up a NAT-T IPSec VPN with one of my client. >> > >> > Is this configuration ok on ipsec.conf for NAT-T? >> > ike esp \ >> > from 10.85.98.16/29 to {10.249.0.0/21} \ >> > peer <IP CLIENT> \ >> > main auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \ >> > quick auth hmac-sha1 enc aes-256 group modp1536 lifetime 86400 \ >> > srcid "<MY PUBLIC IP>" \ >> > psk "********" >> > >> > Something else to force NAT-T? >> > Thanks by advance, >> >> > SÃÆébastien
