Hi everybody,
I just wanted to share little implementation of dynamic vpns on the branch SRX cluster that I did lately.
The case here was to have granular control over to what services and subnets certain group of users have access.
First thing that I tried was to setup couple of dynamic VPNs with different statements in the match condidtions (different destIP and applications), but it wouldn't work. The tunnels would not establish for all of the test users.
So I came up with an alternative solution that works.
Basically what I've done:
1) created new virtual router only for VPN termination
VR-VPN {
instance-type virtual-router;
interface reth2.5;
interface reth4.0;
routing-options {
static {
route 0.0.0.0/0 next-hop 172.16.0.1;
route 10.0.0.0/8 next-hop 192.168.255.1; -->route to protected resources
}
}
}2) configured two access profiles with the SAME authentication mechanism (in my case LDAP) but DIFFERENT address-assigment pools (so that different type of users get differnet IPs)
profile ADMIN_VPN {
authentication-order [ ldap password ];
address-assignment {
pool admin;
}
ldap-options {
base-distinguished-name OU=OU-VPN,DC=lab,DC=local;
search {
search-filter sAMAccountName=;
admin-search {
}
}
}
ldap-server {
10.0.200.1 port 389;
}
}
profile USERS_VPN {
authentication-order [ ldap password ];
address-assignment {
pool users;
}
ldap-options {
base-distinguished-name OU=OU-VPN,DC=lab,DC=local;
search {
search-filter sAMAccountName=;
admin-search {
}
}
}
ldap-server {
10.0.200.1 port 389;
}
}
address-assignment {
pool pool_admin {
family inet {
network 172.20.1.0/24;
range range1 {
low 172.20.1.11;
high 172.20.1.200;
}
xauth-attributes {
primary-dns 10.0.200.1/32;
secondary-dns 8.8.8.8/32;
}
}
}
pool pool_users {
family inet {
network 172.20.11.0/24;
range range2 {
low 172.20.11.11;
high 172.20.11.200;
}
xauth-attributes {
primary-dns 10.0.200.1/32;
secondary-dns 8.8.8.8/32;
}
}
}
3) configured two IKE gateways with distinct xauth profiles configured in step 2
policy dyn_vpn_policy {
mode aggressive;
proposal-set standard;
pre-shared-key ascii-text "$9$8.RLXNJZDqmTg439Ct0OxN-bgajHqz6Ck.01IESy"; ## SECRET-DATA
}
gateway ADMIN_GW {
ike-policy dyn_vpn_policy;
dynamic {
hostname @admin.srx.vpn;
connections-limit 10;
ike-user-type group-ike-id;
}
external-interface reth2.5;
xauth access-profile ADMIN_VPN;
}
gateway USERS_GW {
ike-policy dyn_vpn_policy;
dynamic {
hostname @users.srx.vpn;
connections-limit 10;
ike-user-type group-ike-id;
}
external-interface reth2.5;
xauth access-profile USERS_VPN;
}
4) configured IPSec VPNS:
policy dyn_vpn_policy {
perfect-forward-secrecy {
keys group2;
}
proposal-set standard;
}
vpn USERS_VPN {
ike {
gateway USERS_GW;
ipsec-policy dyn_vpn_policy;
}
}
vpn ADMIN_VPN {
ike {
gateway ADMIN_GW;
ipsec-policy dyn_vpn_policy;
}
}5) Created new security zones for the new VPN virtual router interfaces
security-zone VPN_WAN{
host-inbound-traffic {
system-services {
ping;
https;
ike;
}
}
interfaces {
reth2.5;
}
}
security-zone VPN_LAN{
host-inbound-traffic {
system-services {
ping;
traceroute;
}
}
interfaces {
reth4.0;
}
}
security-zone VR-VPN{
host-inbound-traffic {
system-services {
ping;
traceroute;
}
}
interfaces {
reth3.0;
}
}6) Configured dynamic-vpn stanza:
Here we can configure only one access profie for every user, so this is the part where we realize that we need to have one access profile that can authenticate all of our users. At this point we can differentiate to which subnets a group of users has access to, but this is standard dynamic vpn configuration.
dynamic-vpn {
access-profile ADMIN;
clients {
admins{
remote-protected-resources {
10.0.0.0/8;
}
remote-exceptions {
0.0.0.0/0;
}
ipsec-vpn ADMIN_VPN;
user {
vpn-admin;
}
user-groups {
Administrators;
}
}
users {
remote-protected-resources {
10.10.0.0/16;
}
remote-exceptions {
0.0.0.0/0;
}
ipsec-vpn USERS_VPN;
user {
vpn-test-user;
}
}
}
}7) Configured the actual policies:
First are the standard policies to terminate the VPNs.
from-zone VPN-WAN to-zone VPN-LAN {
policy admin_dyn_vpn {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
tunnel {
ipsec-vpn ADMIN_VPN;
}
}
}
}
policy dyn_vpn_users {
match {
source-address any;
destination-address any;
application any;
}
then {
permit {
tunnel {
ipsec-vpn USERS_VPN;
}
}
}
}
}And then the granular policies I was looking for:
from-zone VR-VPN to-zone SERVERS {
policy DNS {
match {
source-address any;
destination-address any;
application junos-dns-udp;
}
then {
permit;
}
}
policy DYN_VPN_TEST {
match {
source-address VPN_NET_1; --->admin subnet 172.20.1.0/24
destination-address any;
application [ junos-ping junos-https junos-ssh ];
}
then {
permit;
}
}
policy DYN_VPN_TEST_2 {
match {
source-address VPN_NET_2; ---> users subnet 172.20.11.0/24
destination-address any;
application [ junos-ping junos-http junos-https];
}
then {
permit;
}
}
}8) The final touch is to fix the routing. Assuming that the SRX cluster is the default GW for the servers we only need a static routes pointing to the remote users IP addresses:
set routing-options static route 172.20.1.0/24 next-hop 192.168.255.2 set routing-options static route 172.20.11.0/24 next-hop 192.168.255.2
If You have more subnets and planned them toughtfully You could create only one static route towards the VPN VR.
One last thing is that when in cluster mode SRX does not support logical tunnnel interfaces (lt-0/0/0) so I had to use two interfaces on each SRX to facilitate a connection between the main routing instance and the VR. Example connections: node0: ge-0/0/8 <---> ge-0/0/9, node1: ge-5/0/8 <---> ge-5/0/9. and then they were bundled into a classic reth interfaces.
The end result is that two types of users (admin and starndard) can establish simultanious IPSec VPN tunnels with each having his own set of destinations and ports opened.
In the attachement You'll find a graphic illustrating the design to better understand it.
I hope this is helpful :-)
Cheers
IC-00:THREAD_ID-17:RT:jsf_msrpc_alg_check_policy_by_map: lookup poicy for: lsys: 2, v_src_port:32768, v_dst_port:2, src_zone_id = 51,dst_zone_id = 48, src addr:x.x.x.x, dst addr:....