FOR TIPS, gUIDES & TUTORIALS

subscribe to our Youtube

GO TO YOUTUBE

14455 questions

17168 answers

28195 comments

0 members

We are migrating to our new platform at https://community.teltonika.lt. Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
571 views 6 comments
by anonymous
Hello

We've been having problems creating a DMVPN connection on a RUT 955 (spoke) to a Cisco 887 (hub). For some reason the Cisco is rejecting AES 128 with SHA-1 but as far as I can tell that is exactly what our policy is set to and what we have set in the Teltonika. The only thing I can see that is different between the successful negotiations from the other Cisco routers and the unsuccessful Teltonika one is that the Cisco ones have the IP protocol to 47 (GRE) but the Teltonika one has it set to 256. I do have the Teltonika IPSec type set to 'transport' bound to our GRE interface.

Relevant config is below. For our VPN tunnels we use the 192.168.102.0/24 range. .1 is the hub, .123 is the Teltonika spoke.

The RUT 955 is running firmware RUT9_R_00.07.04.3

Would anyone be able to advise on this?

Thanks

/etc/config/dmvpn
config dmvpn '<vpn-name>'
        option config_mode 'spoke'
        option hub_address '<hub-wan>'
        option enabled '1'

/etc/config/ipsec
config remote '<vpn-name>'
        option gateway '<hub-wan>'
        option authentication_method 'psk'
        option service 'dmvpn'
        list tunnel '<vpn-name>_c'
        option force_crypto_proposal '0'
        option _multiple_secrets '0'
        option pre_shared_key '<hex-encoded-text-psk>'
        option remote_identifier '0.0.0.0'
        option local_identifier '0.0.0.0'
        list crypto_proposal '<vpn-name>_ph1_1'
        option enabled '1'

config connection '<vpn-name>_c'
        option ikelifetime '8h'
        option lifetime '8h'
        option aggressive '0'
        option service 'dmvpn'
        option mode 'start'
        option _dpd '0'
        option force_crypto_proposal '0'
        option forceencaps '0'
        option flush '0'
        option local_firewall '1'
        option keyexchange 'ikev1'
        option xauth '0'
        option remote_firewall '0'
        option comp_mode '0'
        list crypto_proposal '<vpn-name>_ph2_1'
        option type 'transport'
        option bind_to '<vpn-name>'

config proposal '<vpn-name>_ph1_1'
        option encryption_algorithm 'des'
        option hash_algorithm 'md5'
        option dh_group 'modp1024'
        option service 'dmvpn'

config proposal '<vpn-name>_ph2_1'
        option encryption_algorithm 'aes128'
        option hash_algorithm 'sha1'
        option dh_group 'no_pfs'
        option service 'dmvpn'

config secret
        option type 'psk'
        option secret '<hex-encoded-text-psk>'
        list id_selector '0.0.0.0'

config ipsec
        option rtinstall_enabled '1'
        option make_before_break '0'

/etc/config/network (abridged)
config interface '<vpn-name>_static'
        option proto 'static'
        option netmask '255.255.255.0'
        option ipaddr '192.168.102.123'
        option device '@<vpn-name>'
        option enabled '1'

config interface '<vpn-name>'
        option proto 'gre'
        option zone 'gre'
        option tunlink 'wan'
        option mtu '1472'
        option peeraddr '<hub-wan>'
        option service 'dmvpn'
        option keep_alive '0'
        option df '1'
        option ttl '255'
        option ikey '0'
        option okey '0'
        option disabled '0'
        option auto '1'

config route '<vpn-name>_route'
        option dep '<vpn-name>'
        option interface '<vpn-name>'
        option table 'main'
        option netmask '255.255.255.0'
        option target '192.168.102.1'
        option service 'dmvpn'
        option enabled '1'

config interface 'wan'
        option proto 'dhcp'
        option device 'eth1'
        option metric '5'

Cisco config (abridged)

crypto keyring dmvpnkeys
  pre-shared-key address 0.0.0.0 0.0.0.0 key <text-psk>
!
crypto isakmp policy 10
 hash md5
 authentication pre-share
 group 2
crypto isakmp key <text-psk> address 0.0.0.0         no-xauth
crypto isakmp profile dmvpn-prf
   keyring dmvpnkeys
   match identity address 0.0.0.0
!
!
crypto ipsec transform-set tr-aes-sha esp-aes esp-sha-hmac
 mode tunnel
crypto ipsec transform-set tr-null-sha esp-null esp-sha-hmac
 mode tunnel
crypto ipsec transform-set tr-des-md5 esp-des esp-md5-hmac
 mode tunnel
crypto ipsec transform-set tr-3des-md5 esp-3des esp-md5-hmac
 mode tunnel
crypto ipsec transform-set tr-3des-sha esp-3des esp-sha-hmac
 mode tunnel
!
!
crypto ipsec profile dmvpn
 set transform-set tr-aes-sha
 set isakmp-profile dmvpn-prf

interface Tunnel0
 ip address 192.168.102.1 255.255.255.0
 no ip redirects
 no ip unreachables
 no ip proxy-arp
 ip mtu 1472
 ip flow ingress
 ip nhrp authentication <same-as-psk>
 ip nhrp network-id <network-id>
 ip nhrp holdtime 300
 ip ospf network broadcast
 ip ospf priority 2
 tunnel source FastEthernet4.10
 tunnel mode gre multipoint
 tunnel key <network-id>
 tunnel protection ipsec profile dmvpn shared
!
by anonymous
Here are some relevant logs

179392: 1y4w: ISAKMP-PAK: (2554):received packet from <spoke-wan> dport 4500 sport 4500 Global (R) QM_IDLE
179393: 1y4w: ISAKMP: (2554):set new node 295634559 to QM_IDLE
179394: 1y4w: ISAKMP: (2554):processing HASH payload. message ID = 295634559
179395: 1y4w: ISAKMP: (2554):processing SA payload. message ID = 295634559
179396: 1y4w: ISAKMP: (2554):processing NAT-OAi payload. addr = <spoke-wan>, message ID = 295634559
179397: 1y4w: ISAKMP: (2554):processing NAT-OAr payload. addr = <hub-wan>, message ID = 295634559
179398: 1y4w: ISAKMP: (2554):Checking IPSec proposal 1
179399: 1y4w: ISAKMP: (2554):transform 1, ESP_AES
179400: 1y4w: ISAKMP: (2554):   attributes in transform:
179401: 1y4w: ISAKMP: (2554):      key length is 128
179402: 1y4w: ISAKMP: (2554):      authenticator is HMAC-SHA
179403: 1y4w: ISAKMP: (2554):      encaps is 4 (Transport-UDP)
179404: 1y4w: ISAKMP: (2554):      SA life type in seconds
179405: 1y4w: ISAKMP: (2554):      SA life duration (basic) of 28800
179406: 1y4w: ISAKMP: (2554):atts are acceptable.
179407: 1y4w: ISAKMP: (2554):Checking IPSec proposal 1
179408: 1y4w: ISAKMP: (2554):transform 2, ESP_AES
179409: 1y4w: ISAKMP: (2554):   attributes in transform:
179410: 1y4w: ISAKMP: (2554):      key length is 128
179411: 1y4w: ISAKMP: (2554):      authenticator is HMAC-SHA256
179412: 1y4w: ISAKMP: (2554):      encaps is 4 (Transport-UDP)
179413: 1y4w: ISAKMP: (2554):      SA life type in seconds
179414: 1y4w: ISAKMP: (2554):      SA life duration (basic) of 28800
179415: 1y4w: ISAKMP: (2554):atts are acceptable.
179416: 1y4w: ISAKMP: (2554):Checking IPSec proposal 1
179417: 1y4w: ISAKMP: (2554):ransform 3, ESP_GCM
179418: 1y4w: ISAKMP: (2554):   attributes in transform:
179419: 1y4w: ISAKMP: (2554):      key length is 128
179420: 1y4w: ISAKMP: (2554):      encaps is 4 (Transport-UDP)
179421: 1y4w: ISAKMP: (2554):      SA life type in seconds
179422: 1y4w: ISAKMP: (2554):      SA life duration (basic) of 28800
179423: 1y4w: ISAKMP: (2554):atts are acceptable.
179424: 1y4w: IPSEC(validate_proposal_request): proposal part #1
179425: 1y4w: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= <hub-wan>:0, remote= <spoke-wan>:0,
    local_proxy= <hub-wan>/255.255.255.255/256/0,
    remote_proxy= <spoke-wan>/255.255.255.255/256/0,
    protocol= ESP, transform= esp-aes esp-sha-hmac  (Transport-UDP),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
179426: 1y4w: map_db_find_best did not find matching map
179427: 1y4w: IPSEC(ipsec_process_proposal): transform proposal not supported for identity:
    {esp-aes esp-sha-hmac }

There were other logs about the transform proposal not supported for the SHA-256 and AES-GCM proposals but those are expected.

Below is a successful Phase 2 from another Cisco 881

179451: 1y4w: ISAKMP-PAK: (2552):received packet from <cisco-wan> dport 4500 sport 53734 Global (R) QM_IDLE
179452: 1y4w: ISAKMP: (2552):set new node 393274008 to QM_IDLE
179453: 1y4w: ISAKMP: (2552):processing HASH payload. message ID = 393274008
179454: 1y4w: ISAKMP: (2552):processing SA payload. message ID = 393274008
179455: 1y4w: ISAKMP: (2552):Checking IPSec proposal 1
179456: 1y4w: ISAKMP: (2552):transform 1, ESP_AES
179457: 1y4w: ISAKMP: (2552):   attributes in transform:
179458: 1y4w: ISAKMP: (2552):      encaps is 3 (Tunnel-UDP)
179459: 1y4w: ISAKMP: (2552):      SA life type in seconds
179460: 1y4w: ISAKMP: (2552):      SA life duration (basic) of 3600
179461: 1y4w: ISAKMP: (2552):      SA life type in kilobytes
179462: 1y4w: ISAKMP:      SA life duration (VPI) of  0x0 0x46 0x50 0x0
179463: 1y4w: ISAKMP: (2552):      authenticator is HMAC-SHA
179464: 1y4w: ISAKMP: (2552):      key length is 128
179465: 1y4w: ISAKMP: (2552):atts are acceptable.
179466: 1y4w: IPSEC(validate_proposal_request): proposal part #1
179467: 1y4w: IPSEC(validate_proposal_request): proposal part #1,
  (key eng. msg.) INBOUND local= <hub-wan>:0, remote= <cisco-wan>:0,
    local_proxy= <hub-wan>/255.255.255.255/47/0,
    remote_proxy= <cisco-wan>/255.255.255.255/47/0,
    protocol= ESP, transform= esp-aes esp-sha-hmac  (Tunnel-UDP),
    lifedur= 0s and 0kb,
    spi= 0x0(0), conn_id= 0, keysize= 128, flags= 0x0
179468: 1y4w: Crypto mapdb : proxy_match
        src addr     : <hub-wan>
        dst addr     : <cisco-wan>
        protocol     : 47
        src port     : 0
        dst port     : 0

This is the output from ipsec 'up <vpn-name>-<vpn-name>_c': <vpn-name>-<vpn-name>_c is the name of the IPSEC interface

initiating Main Mode IKE_SA <vpn-name>-<vpn-name>_c[2] to <hub-wan>
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from <spoke-wan>[500] to <hub-wan>[500] (236 bytes)
received packet: from <hub-wan>[500] to <spoke-wan>[500] (100 bytes)
parsed ID_PROT response 0 [ SA V ]
received NAT-T (RFC 3947) vendor ID
selected proposal: IKE:DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_1024
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from <spoke-wan>[500] to <hub-wan>[500] (236 bytes)
received packet: from <hub-wan>[500] to <spoke-wan>[500] (296 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received DPD vendor ID
received unknown vendor ID: 19:33:e8:6d:ad:5e:22:58:da:f1:a3:6d:cf:c3:87:20
received XAuth vendor ID
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH ]
sending packet: from <spoke-wan>[4500] to <hub-wan>[4500] (68 bytes)
received packet: from <hub-wan>[4500] to <spoke-wan>[4500] (68 bytes)
parsed ID_PROT response 0 [ ID HASH ]
IKE_SA <vpn-name>[2] established between <spoke-wan>[<spoke-wan>]...<hub-wan>[<hub-wan>]
scheduling reauthentication in 28158s
maximum IKE_SA lifetime 28698s
generating QUICK_MODE request 295634559 [ HASH SA No ID ID NAT-OA NAT-OA ]
sending packet: from <spoke-wan>[4500] to <hub-wan>[4500] (244 bytes)
received packet: from <hub-wan>[4500] to <spoke-wan>[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 2846982686 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection '<vpn-name>' failed

1 Answer

0 votes
by anonymous

Hi,

When you create a DMVPN configuration, an IPSec instance should also be created. Have you tried editing the IPSec instance via WebUI and changing the mode from 'transport' to 'tunnel' there? You might as well try forcing encapsulation in the advanced settings.

The proposal lifetime is also different, so you can try changing that (28800 sec (8h) vs 3600 sec on cisco).

Also, do you have access to the hub? I assume there is no transform set for transport mode there?

Kind Regards,

Andzej

by anonymous
Hello

Thanks for your response. I have changed the IPSec mode to tunnel and enabled force encapsulation. I've also changes the proposal lifetime. It still isn't working but the error has changed to "IPSec policy invalidated proposal with error 32" as opposed to error 256.
The Cisco config and logs I showed above were from the hub (but the configuration on the spokes was similar). I didn't see any transform set for transport mode. We do have other spokes coming over UDP tunnels through NAT as well and they are working.

Thanks
by anonymous
Hi,

Could you please double check the Phase 2 proposals on both ends? In case the cisco device is behind the firewall, you may want to enable the remote firewall option in the advanced IPSec settings on RUT.

Also, would it be possible to get a troubleshoot file from RUT955? Additional logs and other related configuration from the Cisco device would be great as well. You can attach those files to your question by editing it. The attached files are only visible to Teltonika moderators.

Kind Regards,
by anonymous
Hello

I'm almost certain the phase 2 proposals are correct - in the troubleshoot file (attached to question) you should see AES128 and SHA1 and this is what is set in the Cisco config. I don't think there is any more relevant Cisco configuration than what I've shown. I've tried with "remote firewall" on and off.

Thanks
by anonymous

Some other things

Our GRE 'tunnel key' is 6 digits (e.g. 123456) but it looks like the web interface limits this to a 16 bit number (max 65535). As far as I can tell this key is a 32 bit number (https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation) and it does seem to work fine if I manually set the ikey and okey in /etc/config/network (see below ip tunnel output)

As shown in the first question the only thing that stands out as different between the successful Cisco associations and the failed Teltonika one was the 47 vs. 256 number (e.g. in the line <hub-wan>/255.255.255.255/256/0). The successful ones have this number set to 47 (which corresponds to the IP Protocol number for GRE: https://en.wikipedia.org/wiki/List_of_IP_protocol_numbers), whereas the Teltonika one has this set to 256. Do you think there could be something wrong with our GRE configuration?

Thanks

Regards

Louis Whitburn

by anonymous
Hello,

Apologies for the late reply. I was away.

Is the issue still relevant?

I see where you coming from when it comes to the 256/47 numbers. However, this should not be an issue in this case.

Troubleshoot file does not contain any relevant logs, just successful keepalive pings. Thus, I will send you a private message.

Kind Regards,

Andzej