Professional Documents
Culture Documents
In todays 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:( Lets get started:
IPsec VPNs
Multipoint tunnels
Traceoptions
On-demand tunnels
Dynamic VPNs
Certificate-based VPNs
PKI
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 nosplit 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
https {
system-generated-certificate
1
2
3
4
5
6
[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 {
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[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 {
18
low 192.168.103.150;
19
high 192.168.103.160;
20
}
21
xauth-attributes {
22
primary-dns 192.168.103.20/32;
23
secondary-dns 8.8.8.8/32;
24
}
25
}
26
}
27 }
28 firewall-authentication {
29
web-authentication {
30
default-profile dyn-vpn-prof1;
31
}
32 }
Create IKE and IPSEC configuration
[edit]
root@srx100-1# show security
policy ike-dyn-pol1 {
mode aggressive;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[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 {
23 perfect-forward-secrecy {
24
keys group2;
25 }
26 proposal-set standard;
27 }
28 vpn vpn-dyn {
29 ike {
30
gateway gw-dyn-1;
31
ipsec-policy ipsec-dyn-pol;
32 }
33 }
Define protected networks i.e for which networks client will route to the tunnel
[edit]
root@srx100-1# show security
access-profile dyn-vpn-prof1;
clients {
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[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 didnt work for me. That is why I put it to the end. I represented previous rules
with dots.
[edit]
root@srx100-1# show security
...
...
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[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 inte
Logical interface fe-0/0/0.0 (In
Flags: SNMP-Traps 0x0 Enca
1 [edit]
2 rootz@srx100-1# run show interfaces fe-0/0/0.0
3
Logical interface fe-0/0/0.0 (Index 84) (SNMP ifIndex 509)
4
Flags: SNMP-Traps 0x0 Encapsulation: ENET2
5
Input packets : 354716
6
Output packets: 219493
7
Security: Zone: srx100-wan
8
Allowed host-inbound traffic : https ike ping ssh
9
Protocol inet, MTU: 1500
10
Flags: Sendbcast-pkt-to-re, Is-Primary
11
Addresses, Flags: Is-Default Is-Preferred Is-Primary
12
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 didnt know
that pulse also does this check:)
1
2
3
4
5
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 didnt 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
dont 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
P
XAUTH username
1
2
3
4
5
6
7
8
9
1
0
1
1
1
2
1
3
1
4
1
5
1
6
1
7
1
8
1
9
2
0
2
1
2
2
2
3
2
4
2
5
XAUTH
192.168.103.157
2
6
2
7
2
8
2
9
3
0
3
1
3
2
3
3
3
4
3
5
3
6
3
7
3
8
3
9
4
0
4
1
4
2
4
3
4
4
4
5
4
6
4
7
4
8
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
4
9
5
0
5
1
5
2
5
3
5
4
5
5
5
6
5
7
5
8
5
9
6
0
6
1
Now I try to ping from this XP client IP address 192.168.103.20 but it doesnt 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
interface vlan.103 {
address {
1
2
3
4
5
[edit]
root@srx100-1# show security nat proxy-arp
interface vlan.103 {
address {
192.168.103.150/32 to 192.168.103.160/32;
6
7
}
}
When I try to ping an available host 192.168.200.254, I can see that I cant ping it.
root@srx100-1> show route 19
inet.0: 75 destinations, 90 route
Restart Complete
1
2
3
4
5
6
7
8
9
10
11
12
1 Oct 1 20:48:32 20:48:32.181525:CID-0:RT: routed (x_dst_ip 192.168.200.254) from srx1002 wan (fe-0/0/0.0 in 0) to vlan.200, Next-hop: 192.168.200.254
3 Oct 1 20:48:32 20:48:32.181525:CID-0:RT:flow_first_policy_search: policy search from zone
4 srx100-wan-> zone mgt (0x0,0x7000500,0x500)
5 Oct 1 20:48:32 20:48:32.181525:CID-0:RT:Policy lkup: vsys 0 zone(6:srx100-wan) ->
6 zone(13:mgt) scope:0
7 Oct 1 20:48:32 20:48:32.181525:CID-0:RT:
192.168.103.156/2048 ->
8 192.168.200.254/16732 proto 1
9 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
1
2
3
4
5
6
7
8
9
10
11
12
[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
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
access-profile dyn-vpn-prof1;
clients {
1
2
3
4
5
6
7
8
9
10
11
12
13
14
[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 lets 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 wont work for 2 reasons;
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[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
policy vpn-allow -net_103 {
match {
1 [edit]
2 root@srx100-1# show security policies from-zone srx100-wan to-zone srx100-wan
3 policy vpn-allow-net_103 {
4
match {
5
source-address net_103;
6
destination-address any;
7
application any;
8
}
9
then {
10
permit;
11 }
12 }
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 doesnt 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.