JNCIE-SEC : Dynamic VPN

In today’s post I will write about how we can setup Dynamic VPN connection
towards an SRX device in several scenarios This is part of my JNCIE-SEC
studies although I am falling very behind my schedule:( Let’s get started:

IPsec VPNs

• Implementation of IPsec VPNs
• Multipoint tunnels
• Policy and route-based VPNs
• Traceoptions
• Dual and backup tunnels
• On-demand tunnels
• DRP over a tunnel
• Dynamic VPNs
• Certificate-based VPNs
• PKI
• Interoperability with 3rd party devices

• Scenario1: Client receives an IP address which is already used inside the local network by other clients and split tunneling active
• Scenario2: Client also accesses the Internet through the tunnel, if the term is correct no-split tunneling

Scenario1
According to the topology, I assume that XP-client is on Internet. Though they are directly connected you can imagine that is a client somewhere on Internet whose default gateway is 192.168.2.254

Based on this, I configure SRX to establish a dynamic vpn connection.

Enable HTTPS connection for the client and make sure no port forwarding/NAT is enabled
for the IP 192.168.2.100

[edit]
root@srx100-1# show system services web-management 
https {
    system-generated-certificate;
    interface fe-0/0/0.0;
}

Create profile, vpn user, assign a pool. We are allocating IPs between 150-160 to
the clients on 192.168.103.0/24 network.

[edit]
root@srx100-1# show access 
profile dyn-vpn-prof1 {
    client vpnclient1 {
        firewall-user {
            password "$9$y13rvLx7VsYoLXUjq.5T"; ## SECRET-DATA
        }
    }
    address-assignment {
        pool vpn-pool-103;
    }
}
address-assignment {
    pool vpn-pool-103 {
        family inet {
            network 192.168.103.0/24;
            range range1 {
                low 192.168.103.150;
                high 192.168.103.160;
            }
            xauth-attributes {
                primary-dns 192.168.103.20/32;
                secondary-dns 8.8.8.8/32;
            }
        }
    }
}
firewall-authentication {
    web-authentication {
        default-profile dyn-vpn-prof1;
    }
}

Create IKE and IPSEC configuration

[edit]
root@srx100-1# show security ike 
policy ike-dyn-pol1 {
    mode aggressive;
    proposal-set standard;
    pre-shared-key ascii-text "$9$RuGhrvdb2aZjKMi.PfzFcyrvX7"; ## SECRET-DATA
}
gateway gw-dyn-1 {
    ike-policy ike-dyn-pol1;
    dynamic {
        hostname rtoodtoo.net;
        connections-limit 2;
        ike-user-type group-ike-id;
    }
    external-interface fe-0/0/0.0;
    xauth access-profile dyn-vpn-prof1;
}                                       


[edit]
root@srx100-1# show security ipsec 
policy ipsec-dyn-pol {
    perfect-forward-secrecy {
        keys group2;
    }
    proposal-set standard;
}
vpn vpn-dyn {
    ike {
        gateway gw-dyn-1;
        ipsec-policy ipsec-dyn-pol;
    }
}

Define protected networks i.e for which networks client will route to the tunnel

[edit]
root@srx100-1# show security dynamic-vpn 
access-profile dyn-vpn-prof1;
clients {
    config-vpn-1 {
        remote-protected-resources {
            192.168.103.0/24;
            192.168.101.0/24;
            192.168.99.0/24;
            192.168.100.0/24;
            192.168.200.0/24;
        }
        ipsec-vpn vpn-dyn;
        user {
            vpnclient1;
        }
    }
}

fe-0/0/0.0 interface belongs to srx100-wan zone and the network that the client receives IP belongs to transit-zone zone. Documentation recommends to put this any any rule on top of any other policy but it didn’t work for me. That is why I put it to the end. I represented previous rules with dots.

[edit]
root@srx100-1# show security policies from-zone srx100-wan to-zone transit-zone 
...
...
...

policy dyn_vpn_allow {
    match {
        source-address any;
        destination-address any;
        application any;
    }
    then {
        permit {
            tunnel {
                ipsec-vpn vpn-dyn;
            }
        }
    }
}

As the final check we make sure that IKE and HTTPS are allowed on the external-interface

[edit]
rootz@srx100-1# run show interfaces fe-0/0/0.0 
  Logical interface fe-0/0/0.0 (Index 84) (SNMP ifIndex 509) 
    Flags: SNMP-Traps 0x0 Encapsulation: ENET2
    Input packets : 354716 
    Output packets: 219493
    Security: Zone: srx100-wan
    Allowed host-inbound traffic : https ike ping ssh
    Protocol inet, MTU: 1500
      Flags: Sendbcast-pkt-to-re, Is-Primary
      Addresses, Flags: Is-Default Is-Preferred Is-Primary
        Destination: 192.168.2/24, Local: 192.168.2.100, Broadcast: 192.168.2.255

Now we connect via pulse client, we have the following routes available on the client: By the way, I had upgraded my SRX100 from 11.4R7.5 to 12.1X44-D20 and pulse informed me during the connection establishment to SRX that a new version of pulse client is available. I didn’t know that pulse also does this check:)

In this screenshot we can see that protected networks

   192.168.103.0/24;
   192.168.101.0/24;
   192.168.99.0/24;
   192.168.100.0/24;
   192.168.200.0/24;

are pushed to the client and client has received 192.168.103.157 IP. We can also check from SRX side as below. What I really didn’t understand is how SRX picks local-identity because to me it looked random. First I thought it picks the lowest network then I noticed that it keeps changing. I don’t know it yet!

We can also see that IKE port is 4500 not 500 for dynamic vpn.

root@srx100-1> show security ike active-peer 
Remote Address                      Port     Peer IKE-ID                         XAUTH username                      Assigned IP
192.168.2.4                         1959     vpnclient1rtoodtoo.net              vpnclient1                          192.168.103.157                   

root@srx100-1> show security ike sa detail 
IKE peer 192.168.2.4, Index 7662200, Gateway Name: gw-dyn-1
  Role: Responder, State: UP
  Initiator cookie: 75c6064ef79a726b, Responder cookie: 21f71a20a8687b4b
  Exchange type: Aggressive, Authentication method: Pre-shared-keys
  Local: 192.168.2.100:4500, Remote: 192.168.2.4:1959
  Lifetime: Expires in 25862 seconds
  Peer ike-id: vpnclient1rtoodtoo.net
  Xauth user-name: vpnclient1
  Xauth assigned IP: 192.168.103.157
  Algorithms:
   Authentication        : hmac-sha1-96 
   Encryption            : aes128-cbc
   Pseudo random function: hmac-sha1
   Diffie-Hellman group  : DH-group-2
  Traffic statistics:
   Input  bytes  :                41667
   Output bytes  :                42976
   Input  packets:                  442
   Output packets:                  445
  Flags: IKE SA is created 
  IPSec security associations: 2 created, 1 deleted
  Phase 2 negotiations in progress: 0

    Negotiation type: Quick mode, Role: Responder, Message ID: 0
    Local: 192.168.2.100:4500, Remote: 192.168.2.4:1959
    Local identity: 192.168.2.100
    Remote identity: vpnclient1rtoodtoo.net
    Flags: IKE SA is created

root@srx100-1> show security ipsec sa detail    
  ID: 268173321 Virtual-system: root, VPN Name: vpn-dyn
  Local Gateway: 192.168.2.100, Remote Gateway: 192.168.2.4
  Local Identity: ipv4_subnet(any:0,[0..7]=192.168.99.0/24)
  Remote Identity: ipv4(any:0,[0..3]=192.168.103.157)
  Version: IKEv1
    DF-bit: clear
    Policy-name: dyn_vpn_allow
  Port: 1959, Nego#: 9, Fail#: 0, Def-Del#: 0 Flag: 608829 
  Tunnel Down Reason: SA not initiated
    Direction: inbound, SPI: fc06dd11, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 1809 seconds
    Lifesize Remaining:  499989 kilobytes
    Soft lifetime: Expires in 1246 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

    Direction: outbound, SPI: 4a5f8e3a, AUX-SPI: 0
                              , VPN Monitoring: -
    Hard lifetime: Expires in 1809 seconds
    Lifesize Remaining:  499989 kilobytes
    Soft lifetime: Expires in 1246 seconds
    Mode: Tunnel(0 0), Type: dynamic, State: installed
    Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)
    Anti-replay service: counter-based enabled, Replay window size: 64

Now I try to ping from this XP client IP address 192.168.103.20 but it doesn’t work. Because I forgot to add the proxy-arp config. Because client is receiving IP from an inside network, SRX has to do proxy arp on behalf of its vpn clients.

Once I add the following proxy-arp on vlan.103 interface, ping works. Now I can reach the internal resources on 192.168.103.20 network or in general
networks in transit-zone.

[edit]
root@srx100-1# show security nat proxy-arp 
interface vlan.103 {
    address {
        192.168.103.150/32 to 192.168.103.160/32;
    }
}

When I try to ping an available host 192.168.200.254, I can see that I can’t ping it.

root@srx100-1> show route 192.168.200.254 terse     

inet.0: 75 destinations, 90 routes (75 active, 0 holddown, 1 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both

A Destination        P Prf   Metric 1   Metric 2  Next hop         AS path
* 192.168.200.0/24   D   0                       >vlan.200     
                     B 170        100         20 >192.168.3.3      8500 I

root@srx100-1> show interfaces vlan.200 | match Zone 
    Security: Zone: mgt

We can see that this network is connected to vlan.200 interface which is in mgt zone.

A flow traceoptions is also showing that it is denied by default policy.

Oct  1 20:48:32 20:48:32.181525:CID-0:RT:  routed (x_dst_ip 192.168.200.254) from srx100-wan (fe-0/0/0.0 in 0) to vlan.200, Next-hop: 192.168.200.254
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:flow_first_policy_search: policy search from zone srx100-wan-> zone mgt (0x0,0x7000500,0x500)
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:Policy lkup: vsys 0 zone(6:srx100-wan) -> zone(13:mgt) scope:0
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:             192.168.103.156/2048 -> 192.168.200.254/16732 proto 1
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:Policy lkup: vsys 0 zone(5:Unknown) -> zone(5:Unknown) scope:0
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:             192.168.103.156/2048 -> 192.168.200.254/16732 proto 1
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:  app 0, timeout 60s, curr ageout 60s
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:  packet dropped, denied by policy
Oct  1 20:48:32 20:48:32.181525:CID-0:RT:  denied by policy default-policy-00(2), dropping pkt

What I found a bit odd here is that context is from the public zone (srx100-wan) towards mgt zone. This creates a challenge here as I have to put the following policy to let this traffic through;

[edit]
root@srx100-1# show security policies from-zone srx100-wan to-zone mgt 
policy vpn-to-mgt {
    match {
        source-address net_192.168.103;
        destination-address mgtnet-200;
        application any;
    }
    then {
        permit;
    }
}

To be honest as this is my test system, I added this policy. In a production network, I believe vpn client destination networks should be restricted to one destination zone.

So the rule is:
If the destination network that the client is trying to reach is in a different destination zone than the main ipsec policy is created in i.e in our example transit-zone, then we have to create another policy from srx100-wan to the new zone.

Scenario2

In this scenario, we want the client to receive default gateway from the SRX and force the client to go through SRX for everything i.e even for internet it has to go through SRX. With this current config, client will only use tunnel for the remote-protected-networks. Now I will change this;

[edit]
root@srx100-1# show security dynamic-vpn 
access-profile dyn-vpn-prof1;
clients {
    config-vpn-1 {
        remote-protected-resources {
            0.0.0.0/0;
        }
        ipsec-vpn vpn-dyn;
        user {
            vpnclient1;
        }
    }
}

Now let’s see what the client received;

As we can see we have two default gateways but the one sent from SRX has metric 1. So now we are supposed to send all traffic towards SRX but Internet won’t work for 2 reasons;

1) Client has a private IP which must be translated
2) Another security policy on the external interface must be added

1) Because from SRX point of view, packet is coming from srx100-wan zone and for Internet it leaves again from srx100-wan external interface, we create nat from srx100-wan to srx100-wan for the client source address 192.168.103.0/24

 
[edit]
root@srx100-1# show security nat source rule-set srx100-wan-to-srx100-wan 
from zone srx100-wan;
to zone srx100-wan;
rule dyn_vpn_clients {
    match {
        source-address 192.168.103.0/24;
        destination-address 0.0.0.0/0;
    }
    then {
        source-nat {
            interface;
        }
    }
}

2 We create the security policy for the same context like nat for the same source address.

[edit]
root@srx100-1# show security policies from-zone srx100-wan to-zone srx100-wan 
policy vpn-allow-net_103 {
    match {
        source-address net_103;
        destination-address any;
        application any;
    }
    then {
        permit;
    }
}

After this config, I can see that all traffic from my client is going through the SRX device. Setting a security policy in the external zone like this doesn’t look perfect but this the current design as far as I can see.

This was a long post I suppose. If you have any feedback, please let me know.