[j-nsp] [c-nsp] Help with an IPSec scenario

Tom Storey tom at snnap.net
Fri Mar 13 17:01:21 EDT 2015


Excuse the long post, but I just want all this out in the open in case
someone else finds it useful. :-)

Here are my Cisco and Juniper configs for the IPSec portion. Add in
the EEM script to help with updating the tunnel destination IP on the
Cisco, and you'll need some kind of event script for the Juniper to
update a dynamic DNS hostname somewhere to complete the "solution". I
think I found one on Junipers website, or maybe it was made by someone
else (apologies if I got the credits for that mixed up!)

interfaces {
    st0 {
        unit 3 {
            description "IPv4 tunnel to c2821";
            family inet {
                mtu 1420;
                address 172.25.144.243/31;
            }
        }
    }
}
event-options {
    policy dyn-dns-updater {
        events SYSTEM;
        attributes-match {
            SYSTEM.message matches "EVENT Add at-1/0/0.0";
        }
        then {
            event-script dyn-dns-update.xslt;
        }
    }
    event-script {
        file dyn-dns-update.xslt;
    }
}
security {
    ike {
        proposal ike-proposal-j2c-1 {
            authentication-method pre-shared-keys;
            dh-group group5;
            authentication-algorithm sha-256;
            encryption-algorithm aes-256-cbc;
            lifetime-seconds 28800;
        }
        policy ike-policy-j2c-1 {
            mode main;
            proposals ike-proposal-j2c-1;
            pre-shared-key ascii-text "SECRET-DATA"; ## SECRET-DATA
        }
        gateway ike-gateway-j2c-1 {
            ike-policy ike-policy-j2c-1;
            address 1.2.3.4;
            local-identity hostname srx110c2821;
            external-interface at-1/0/0.0;
        }
    }
    ipsec {
        proposal ipsec-proposal-j2c-1 {
            protocol esp;
            authentication-algorithm hmac-sha-256-128;
            encryption-algorithm aes-256-cbc;
            lifetime-seconds 3600;
            lifetime-kilobytes 4608000;
        }
        policy ipsec-policy-j2c-1 {
            proposals ipsec-proposal-j2c-1;
        }
        vpn ipsec-vpn-j2c-1 {
            bind-interface st0.3;
            ike {
                gateway ike-gateway-j2c-1;
                ipsec-policy ipsec-policy-j2c-1;
            }
            establish-tunnels immediately;
        }
    }
}



crypto keyring j2c-keyring
  pre-shared-key address 0.0.0.0 0.0.0.0 key SECRET-DATA
!
crypto isakmp policy 1
 encr aes 256
 hash sha256
 authentication pre-share
 group 5
crypto isakmp profile j2c-1
   keyring j2c-keyring
   match identity user-fqdn srx110c2821
!
crypto ipsec transform-set ESP_AES256 esp-aes 256 esp-sha256-hmac
!
crypto ipsec profile j2c-1
 set transform-set ESP_AES256
 set isakmp-profile j2c-1
!
interface Tunnel0
 description IPv4 tunnel to srx110
 ip address 172.25.144.242 255.255.255.254
 ip mtu 1420
 tunnel source Dialer0
 tunnel mode ipsec ipv4
 ! tunnel destination set by EEM script
 tunnel protection ipsec profile j2c-1
!

Pastebin version (friendlier formatting etc): http://pastebin.com/nPXTcdvj

On 13 March 2015 at 19:08, Nick Cutting <ncutting at edgetg.co.uk> wrote:
> Very nice, your EMM is much better than mine !
>
> -----Original Message-----
> From: Tom Storey [mailto:tom at snnap.net]
> Sent: 13 March 2015 18:09
> To: Nick Cutting
> Cc: cisco-nsp; juniper-nsp at puck.nether.net
> Subject: Re: [c-nsp] Help with an IPSec scenario
>
> For anyone else that wants to do something like this, I whipped up a EEM applet:
>
> event manager applet update_tunnel0_dest authorization bypass  event none  event timer watchdog time 60  action 1.0 set ifname "Tunnel0"
>  action 1.1 set tundest "dyndns.hostname"
>  action 2.0 cli command "show interface $ifname"
>  action 2.1 regexp "(up|down), line protocol" $_cli_result result ifadminstatus  action 2.2 if $_regexp_result eq 1  action 2.2.0 if $ifadminstatus eq "up"
>  action 2.2.0.0 regexp "line protocol is (up|down)" $_cli_result result ifoperstatus  action 2.2.0.1 if $ifoperstatus eq "down"
>  action 2.2.0.1.0 syslog msg "Set new destination for $ifname"
>  action 2.2.0.1.1 cli command "enable"
>  action 2.2.0.1.2 cli command "configure terminal"
>  action 2.2.0.1.3 cli command "interface $ifname"
>  action 2.2.0.1.4 cli command "tunnel destination $tundest"
>  action 2.2.0.1.5 cli command "end"
>  action 2.2.0.2 end
>  action 2.2.1 end
>  action 2.3 end
>
> Just re-name it to something more useful, adjust the ifname and tundest variables, and perhaps the timer interval if you want it to run more frequently than 60 seconds.
>
> The odd thing is that I have a Cisco behind NAT firing up an IPSec tunnel to a Juniper, and that works just fine. Strange that it wouldnt work the other way around...
>
> On 13 March 2015 at 17:06, Tom Storey <tom at snnap.net> wrote:
>> Hi Nick,
>>
>> Yeah, I dont believe Juniper support NHRP, thats a Cisco thing.
>>
>> I just tried replacing my Tunnel config with a Virtual-Template
>> config, I now get an IPSec SA, and a Virtual-Access interface is
>> created and seems to be receiving packets if I run a ping from the
>> Juniper...!
>>
>> How to get an IP from my ptp subnet on to it to permit routing back in
>> the other direction is the next question...
>>
>> I may yet have to surrender and do something similar to what youve
>> done. A little less elegant, but it will work at the least.
>>
>> Thanks!
>>
>> On 13 March 2015 at 16:48, Nick Cutting <ncutting at edgetg.co.uk> wrote:
>>> Further to this, I don't think it is possible without a hardcoded destination on the VTI tunnel interface.  The reason it works with dynamic spoke public addresses with DMVPN is the dynamic spoke does a NHRP registration, and the tunnel endpoint is built using this information.
>>>
>>> There is no such process with static VTI.
>>>
>>> Phase1 is fine, then Phase2 fails with debug messages that don't necessary explain why this won't work.
>>>
>>> I don't think Junos supports NHRP, but I could be wrong.
>>>
>>>
>>> -----Original Message-----
>>> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
>>> Of Nick Cutting
>>> Sent: 13 March 2015 16:25
>>> To: Tom Storey; cisco-nsp; juniper-nsp at puck.nether.net
>>> Subject: Re: [c-nsp] Help with an IPSec scenario
>>>
>>> I tried to get this to work for weeks, in the end, I used dyn-dns on the Juniper side, and ran an EMM script on the cisco router (2911 - 15.3) that looked up the dyn-dys juniper name, then rewrote the tunnel destination, every 5 minutes.
>>>
>>> I can't see your config, as it is blocked at my work - I was using 0.0.0.0/0 as the proxy id on the juniper side, and a "normal" static VTI tunnel on the Juniper side.
>>>
>>> This works, as it is my home setup back to the office.
>>>
>>> I did not try DVTI, And I'm not sure if it uses NHRP in the same way as DMVPN would (with no gre) - which wouldn't probably work with a juniper routed tunnel anyway.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: cisco-nsp [mailto:cisco-nsp-bounces at puck.nether.net] On Behalf
>>> Of Tom Storey
>>> Sent: 13 March 2015 15:35
>>> To: cisco-nsp; juniper-nsp at puck.nether.net
>>> Subject: [c-nsp] Help with an IPSec scenario
>>>
>>> Hi everyone,
>>>
>>> Trying to establish an IPSec tunnel (route based) between a Juniper SRX and a Cisco IOS router.
>>>
>>> The topology is two routers with DSL services, the SRX is on a dynamic IP, the Cisco on a static. No NAT is involved in the path between the two routers.
>>>
>>> Heres the configs Im working on: http://pastebin.com/gUEFVTau
>>>
>>> Basically what Im getting is this...
>>>
>>> In main mode, phase 1 is OK, and I get probably 99% of the way in phase 2, but it doesnt quite complete, with errors like "proxy identities not supported".
>>>
>>> I can fix this by configuring Tunnel0's destination as the IP of the
>>> SRX /at the time/ and can then ping across the tunnel. But this
>>> obviously isnt a long term solution because if the IP of the SRX
>>> changes (and it does, frequently, because the DSL is notoriously
>>> unstable) then the VPN stops working.
>>>
>>> So I try to go aggressive mode, but this is even worse, with phase 1 not completing with errors like "IKE packet from x.x.x.x was not encrypted and it should've been", and never really making it past AG_INIT_EXCH.
>>>
>>> This is a debug of aggressive mode: http://pastebin.com/RUAaXDyE
>>>
>>> Based on my supplied configs, can anyone help me come up with a solution that allows the SRX to initiate a connection from any random IP, and the Cisco accepts it but I dont have to configure the IP of the SRX on the Cisco in order for it to work? I feel like Im tantalisingly close, but after several hours at it so far and copious amounts of googling, I just cant see the solution...
>>>
>>> Thanks.
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>>> _______________________________________________
>>> cisco-nsp mailing list  cisco-nsp at puck.nether.net
>>> https://puck.nether.net/mailman/listinfo/cisco-nsp
>>> archive at http://puck.nether.net/pipermail/cisco-nsp/
>>>
>


More information about the juniper-nsp mailing list