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
