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 <mikyde...@yahoo.fr> 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 <seb.mor...@gmail.com> 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 <mikyde...@yahoo.fr> 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 <seb.mor...@gmail.com> 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
