Quantcast

Isakmpd and NAT-T

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Isakmpd and NAT-T

Sébastien Morand
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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Mik J
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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Philipp
Am 14.03.2017 01:46 schrieb Mik J:
> 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.
>

Since I've seen this on several occassions, check that isakmpd is /not/
having the flag -T. But you might want to use -L and look into the
resulting
/var/run/isakmpd.pcap (hint: tail -fc+0 isakmpd.pcap|tcpdump -netttvvr
-)
and watch out for the vendor lines in the proposal if NAT-T is actually
advertised - and of course allow 4500/udp in both directions.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Sébastien Morand
In reply to this post by Mik J
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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Mik J
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 alsosysctl -a | grep esp



    Le Jeudi 16 mars 2017 16h33, Sébastien Morand <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Stuart Henderson
In reply to this post by Sébastien Morand
On 2017-03-16, Sébastien Morand <[hidden email]> wrote:
> Thank you Mike for your answer. There is nothing more like you said.
> Actually we succeed in phase 1 but not in phase 2.
..
> 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
..
> 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
..
> 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.

isakmpd sends the wrong encapsulation mode (always TUNNEL, not
UDP_ENCAPSULATED_TUNNEL). But also last time I tried this (in 2011)
Cisco hadn't caught up with the RFC and actually required the
UDP_ENCAPSULATED_TUNNEL_DRAFT value from the draft nat-t spec.

This would cause a phase 2 failure, an ASA reports it like
"[IKEv1]Phase 2 failure: Mismatched attribute types for class
 Encapsulation Mode: Rcv'd: Tunnel Cfg'd: UDP Tunnel(NAT-T)"

Here's an old post about it with an isakmpd diff that was working
against Cisco. What I don't know is whether it harms interop with
anything else.
 
http://marc.info/?l=openbsd-tech&m=131244805816474

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Claer-2
Hello,

On Fri, Mar 17 2017 at 22:07, Stuart Henderson wrote:

> On 2017-03-16, Sébastien Morand <[hidden email]> wrote:
> > Thank you Mike for your answer. There is nothing more like you said.
> > Actually we succeed in phase 1 but not in phase 2.
> ..
> > 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
> ..
> > 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
> ..
> > 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.
>
> isakmpd sends the wrong encapsulation mode (always TUNNEL, not
> UDP_ENCAPSULATED_TUNNEL). But also last time I tried this (in 2011)
> Cisco hadn't caught up with the RFC and actually required the
> UDP_ENCAPSULATED_TUNNEL_DRAFT value from the draft nat-t spec.
>
> This would cause a phase 2 failure, an ASA reports it like
> "[IKEv1]Phase 2 failure: Mismatched attribute types for class
>  Encapsulation Mode: Rcv'd: Tunnel Cfg'd: UDP Tunnel(NAT-T)"
>
> Here's an old post about it with an isakmpd diff that was working
> against Cisco. What I don't know is whether it harms interop with
> anything else.
>  
> http://marc.info/?l=openbsd-tech&m=131244805816474

I ran with this patch on production for nearly 2 years. It didn't cause any
issue interoperating with few kind of devices. I successfully configured VPN
with ASA, Juniper, Fortinet, StormShield and Windows on the other side.
If there were some side effects, they were not visible.

Claer

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Sébastien Morand
In reply to this post by Mik J
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Isakmpd and NAT-T

Sébastien Morand
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 <[hidden email]>
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]>
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

Loading...