IPSec to Cisco ASR 1013

  • Hi. I am trying to connect a IPSec tunnel to a 3rd party service. I've connected to Cisco ASA before, but nut ASR - Not even familiar with them

    Hoping someone here can make sense of this. I've tried a pile of variations. The other side is pretty confident they have their end correct as they have multiple clients connected (this is the first pfsense they are aware of though)

    Here is config we have in place at the Cisco (what I was given). I changed s few things for privacy

    A0040NtEpsBpr03#show run | section 922
    vrf definition M922S
    description MBS_M922S
    address-family ipv4
    route-replicate from vrf FVRF unicast static route-map rm_Default_Only
    peer MBS_M922S
    address XXX.XXX.212.30
    pre-shared-key 1234
    crypto ikev2 profile IKEv2_Profile_MBS_M922S
    match fvrf FVRF
    match identity remote address XXX.XXX.212.30
    authentication local pre-share
    authentication remote pre-share
    keyring local IKEv2_KEY
    ivrf M922S
    track 922 ip sla 922 reachability
    delay down 180 up 180
    crypto map Map1 922 ipsec-isakmp
    description MBS_M922S
    set peer XXX.XXX.212.30
    set transform-set Esp_aes256-sha256
    set ikev2-profile IKEv2_Profile_MBS_M922S
    match address acl_MBS_M922S
    interface Loopback922
    vrf forwarding M922S
    ip address
    interface Tunnel922
    description MBS_vrf:M922S-A0040_EPGW_Tunnel
    vrf forwarding M922S
    ip address XXX.XXX.245.240
    ip tcp adjust-mss 1363
    load-interval 30
    tunnel source Loopback99
    tunnel destination
    ip route vrf M922S Tunnel922
    ip access-list extended acl_MBS_M922S
    remark Mobile to Server
    permit ip any
    remark Monitoring
    permit ip host XXX.XXX.245.240 host

    A0040NtEpsBpr03#show crypto session ivrf M922S detail
    Crypto session current status

    Code: C - IKE Configuration mode, D - Dead Peer Detection
    K - Keepalives, N - NAT-traversal, T - cTCP encapsulation
    X - IKE Extended Authentication, F - IKE Fragmentation
    R - IKE Auto Reconnect

    Interface: GigabitEthernet0/0/0 GigabitEthernet3/0/0
    Session status: DOWN
    Peer: XXX.XXX.212.30 port 500 fvrf: FVRF ivrf: M922S
    Desc: (none)
    Phase1_id: (none)
    IPSEC FLOW: permit ip
    Active SAs: 0, origin: crypto map
    Inbound: #pkts dec'ed 0 drop 0 life (KB/Sec) 0/0
    Outbound: #pkts enc'ed 0 drop 18 life (KB/Sec) 0/0
    IPSEC FLOW: permit ip host XXX.XXX.245.240 host
    Active SAs: 0, origin: crypto map
    Inbound: #pkts dec'ed 64 drop 0 life (KB/Sec) 0/0
    Outbound: #pkts enc'ed 64 drop 17829 life (KB/Sec) 0/0

    In pfSense:
    P1 General Information
    Key Exchange version = IKEv2
    Internet Protocol = IPv4
    Interface = WAN
    Remote Gateway = XXX.XXX.245.222

    Phase 1 Proposal (Authentication)
    Authentication Method = Mutual PSK
    My identifier = My IP Address (I've tried just 'IP Address' with my public IP as well)
    Peer identifier = Peer IP Address (I've tried 'Any' and 'IP Address' as well)
    Pre-Shared Key = 1234

    Phase 1 Proposal (Encryption Algorithm)
    Encryption Algorithm
    Algorithm = AES
    Key length = 256 bits
    Hash = SHA256
    DH Group = 16 (4096 bit)

    Lifetime (Seconds) = 86400

    Advanced Options
    Disable rekey Disables renegotiation when a connection is about to expire. = OFF
    Margintime (Seconds) = BLANK
    Disable Reauth
    Whether rekeying of an IKE_SA should also reauthenticate the peer. In IKEv1, reauthentication is always done. = OFF
    Responder Only
    Enable this option to never initiate this connection from this side, only respond to incoming requests. = OFF

    MOBIKE = Disable
    Set this option to control the use of MOBIKE
    Split connections
    Enable this to split connection entries with multiple phase 2 configurations. Required for remote endpoints that support only a single traffic selector per child SA. = ON
    Dead Peer Detection Enable DPD = ON
    Delay = 10
    Max failures = 5

    There are 2 P2’s in play here
    Mode = Tunnel IPv4
    Local Network Type = Address
    Address =
    NAT/BINAT translation = None
    Remote Network Type = Address
    Address = XXX.XXX.245.240

    P2 Proposal
    Encryption Algorithms = AES 256 bits
    Hash Algorithms = SHA256
    PFS key group = off
    Lifetime = 3600
    Automatically Pin host = BLANK

    Tunneled IPs:
    Mode = Tunnel IPv4
    Local Network Type = Network
    Address =
    NAT/BINAT translation = None
    Remote Network Type = Network
    Address =

    P2 Proposal
    Encryption Algorithms = AES 256 bits
    Hash Algorithms = SHA256
    PFS key group = off
    Lifetime = 3600
    Automatically Pin host = BLANK

    Now for the logs (oldest at the top) are attached. This is one with my IP not forced and the other with it forced. I can see there is an Authentication error, but I don't see a misalignment anywhere. There is also a complaint about the vendor id, I don't know what that exactly means here either though

    Any insight here would be fantastic!

  • @tgreen The logs are being marked as spam for some reason
    IPsec Logs.7z

  • @tgreen

    You should check IPSEC settings ( phase 1) (My identifier / Remote identifier)
    The logs say that is not found preshared-key

    fb424782-b753-4994-a747-4ea7fddeb57e-image.png charon: 13[IKE] <con3000|1> authentication of 'XXX.XXX.212.30' (myself) with pre-shared key
    charon: 13[IKE] <con3000|1> no shared key found for 'XXX.XXX.212.30' - 'XXX.XXX.245.222'

    73ba7734-2274-4785-b939-0ae7b0b81e2e-image.png 28.03.2019 13:40 charon: 12[CFG] <con3000|17> selected peer config 'con3000'
    28.03.2019 13:40 charon: 12[IKE] <con3000|17> no shared key found for '%any' - 'XXX.XXX.245.222'

  • @Konstanti
    Ya, I can't tell you how many times I verified the IPSec settings
    Magically, the connection was established last night as I left it on while doing some other work. When I returned to have another look, the connection was made. I tried this current configuration multiple times to no avail, so I am baffled as to what the resolution was

    I'm booking a meeting with a guy at the other side to start pulling parts and pieces apart to determine the issue

    One thing I noticed is that the initial attempts to connect were using port 4500 and the established tunnel is on 500 (I have no firewall logs blocking this and I have rules on WAN in place explicitly allowing UDP 500/4500 and ESP.

    Perhaps their end isn't liking the 4500 (they told me they are good with the UDP 4500 mind you)

    Sort of feels like Cisco just not wanting to play nice in the sandbox with the other kids.

    I'll update with any resolution(s) or comments here

Log in to reply