We will focus more on configuration and testing rather than VPN theory as the Internet is full of great resources in that respect. No NAT in this one either to keep it more simple and just focused on the VPN side of things. We will do a seperate Blog for VPN troubleshooting.
Here is a layer 3 view of the network we will be using..
Specifically we want to create VPNs between the 3 networks connected to the Checkpoint and a remote 3rd party server connected to the SRX (192.168.40.50).
We only want to permit ssh.
The server will always be the destination for connections. In our scenario the SRX is ours as well so we will have to manage it over the VPN.
The Checkpoint is R75.47 GAIA and the SRX is 210HE running 12.1X45-D15.5.
Checkpoints are more commonly configured with policy based VPNs though they can do route based as well. For SRXs it’s the opposite way. So in this lab we will make the Checkpoint happy by doing policy based VPN. We will therefore expect to see a pair of IPSEC SAs for each src/dst network pair.
We only want to permit ssh.
The server will always be the destination for connections. In our scenario the SRX is ours as well so we will have to manage it over the VPN.
The Checkpoint is R75.47 GAIA and the SRX is 210HE running 12.1X45-D15.5.
Checkpoints are more commonly configured with policy based VPNs though they can do route based as well. For SRXs it’s the opposite way. So in this lab we will make the Checkpoint happy by doing policy based VPN. We will therefore expect to see a pair of IPSEC SAs for each src/dst network pair.
1) CHECKPOINT SETUP
a) Check Basic Connectivity (Setup routing)
As it’s a lab environment the first thing I do is make sure that the sources have connectivity to the destination by SSHing to the server without the VPN in place. This tells me I have all the necessary routes I need correctly set.
GAIA static route..
set static-route default nexthop gateway address 10.1.1.9 on
Or course in the real world you often don’t have the luxury as your dealing with 3rd parties . Still, get your routing done as best you can.
b) Define Encryption Domain
As all the networks behind the Checkpoint need to access the remote server over the VPN, all 3 networks need to be in the encryption domain.
Here is the encryption domain group object..
Now the above group is applied to the Checkpoint firewall object as its VPN Domain..
You may note that the firewall has only 3 interfaces - 192.168.50.0 is not there! Our network 192.168.50.0 is actually behind a router sitting on CP3 eth2 hence the topology for eth2 in the above picture (CP3_eth2 is a group that has the networks 192.168.50.0 and 192.168.97.0). Logically, from the point of the VPN configuration, you can still think of the topology as presented in the initial layer 3 view diagram.
c) Define the VPN
Before you get into the actual configuration, define the VPN phase1 and phase 2 properties and be in agreement about them with the remote end!
We define our VPN with these properties:
Phase 1..
Encryption Algorithm - AES 256
Authentication - SHA1
DH group - 2
Lifetime - 86400 seconds
Preshared keys
Phase 2..
Encryption Algorithm - AES 256
Authentication - SHA1
PFS - Yes, group 2
Lifetime - 3600 seconds
Protocol - ESP
A not uncommon proposal set.
To setup on the Checkpoint..
Go to the SmartDashboard IPSec VPN tab.
Right click next to the existing VPN communities and select New Community > Star
(Star as we will consider the remote SRX as the “Satellite Gateway”)
Here is the VPN config in pictures from the Community Properties of our new VPN shown in the same order as the menu entries for the Community Properties.
Note: Accept all encrypted traffic is off as we will define what we want to permit and encrypt through the firewall policy.
Note: The remote Satellite Gateway is defined as an “Interoperable Device”
(Right click on Network Objects and select: New > Interoperable Device
(Right click on Network Objects and select: New > Interoperable Device
The below highlighted setting is the default and is what the SRX (Or any IPSec standards compliant device) would expect in policy based routing.
Define the shared secret.
d) Define the encryption domain for the remote gateway (SRX) and apply it.
2) SRX SETUP
a) Check Basic Connectivity (Setup routing)
Setup the default route..
user@SRX> show configuration routing-options
static {
route 0.0.0.0/0 next-hop 10.222.222.1;
}
The other network (192.168.40.0) is directly connected to the SRX so we don’t need to add anything for that.
b) We don’t explicitly define the encryption domain on the SRX as we do on the Checkpoint, instead it’s defined by the source and dest IPs in the policy rule.
c) Define the VPN
Here is the complete matching SRX VPN config to the Checkpoint config above.
user@SRX> show configuration security
ike {
traceoptions {
file VPN size 1m files 5;
flag ike;
flag all;
}
respond-bad-spi;
proposal aes-phase1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 86400;
}
policy corp-phase1-pol {
mode main;
proposals aes-phase1;
pre-shared-key ascii-text "$9$MW5WxdbagaJDdrtmTQn6"; ## SECRET-DATA
}
gateway corp-gw {
ike-policy corp-phase1-pol;
address 10.1.1.1;
external-interface vlan.0;
}
}
ipsec {
proposal aes-phase2 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;
}
policy corp-phase2-pol {
perfect-forward-secrecy {
keys group2;
}
proposals aes-phase2;
}
vpn corp-vpn {
ike {
gateway corp-gw;
ipsec-policy corp-phase2-pol;
}
}
}
d) Create the needed policy objects
user@SRX# run show configuration security address-book global
address net_192.168.97.0/24 192.168.97.0/24;
address net_192.168.40.0/24 192.168.40.0/24;
address net_192.168.10.0/24 192.168.10.0/24;
address net_192.168.50.0/24 192.168.50.0/24;
3) Make sure to permit IKE on the outside of the peer
user@SRX# run show configuration security zones
security-zone trust {
host-inbound-traffic {
system-services {
ike;
}
'All' under system-services works too.
user@SRX> show configuration routing-options
static {
route 0.0.0.0/0 next-hop 10.222.222.1;
}
The other network (192.168.40.0) is directly connected to the SRX so we don’t need to add anything for that.
b) We don’t explicitly define the encryption domain on the SRX as we do on the Checkpoint, instead it’s defined by the source and dest IPs in the policy rule.
c) Define the VPN
Here is the complete matching SRX VPN config to the Checkpoint config above.
user@SRX> show configuration security
ike {
traceoptions {
file VPN size 1m files 5;
flag ike;
flag all;
}
respond-bad-spi;
proposal aes-phase1 {
authentication-method pre-shared-keys;
dh-group group2;
authentication-algorithm sha1;
encryption-algorithm aes-256-cbc;
lifetime-seconds 86400;
}
policy corp-phase1-pol {
mode main;
proposals aes-phase1;
pre-shared-key ascii-text "$9$MW5WxdbagaJDdrtmTQn6"; ## SECRET-DATA
}
gateway corp-gw {
ike-policy corp-phase1-pol;
address 10.1.1.1;
external-interface vlan.0;
}
}
ipsec {
proposal aes-phase2 {
protocol esp;
authentication-algorithm hmac-sha1-96;
encryption-algorithm aes-256-cbc;
lifetime-seconds 3600;
}
policy corp-phase2-pol {
perfect-forward-secrecy {
keys group2;
}
proposals aes-phase2;
}
vpn corp-vpn {
ike {
gateway corp-gw;
ipsec-policy corp-phase2-pol;
}
}
}
d) Create the needed policy objects
user@SRX# run show configuration security address-book global
address net_192.168.97.0/24 192.168.97.0/24;
address net_192.168.40.0/24 192.168.40.0/24;
address net_192.168.10.0/24 192.168.10.0/24;
address net_192.168.50.0/24 192.168.50.0/24;
3) Make sure to permit IKE on the outside of the peer
user@SRX# run show configuration security zones
security-zone trust {
host-inbound-traffic {
system-services {
ike;
}
'All' under system-services works too.
3) VPN POLICY FOR BOTH PEERS
Checkpoint side..
SRX side..
user@SRX> show configuration security policies
from-zone trust to-zone untrust {
policy SERVER_ACCESS_IN {
match {
source-address net_192.168.97.0/24;
destination-address net_192.168.40.0/24;
application junos-ssh;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_IN_2 {
match {
source-address net_192.168.50.0/24;
destination-address net_192.168.40.0/24;
application junos-ssh;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_IN_3 {
match {
source-address net_192.168.10.0/24;
destination-address net_192.168.40.0/24;
application junos-ssh;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
}
from-zone untrust to-zone trust {
policy SERVER_ACCESS_OUT {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.97.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_OUT_2 {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.50.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_OUT_3 {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.10.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
user@SRX> show configuration security policies
from-zone trust to-zone untrust {
policy SERVER_ACCESS_IN {
match {
source-address net_192.168.97.0/24;
destination-address net_192.168.40.0/24;
application junos-ssh;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_IN_2 {
match {
source-address net_192.168.50.0/24;
destination-address net_192.168.40.0/24;
application junos-ssh;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_IN_3 {
match {
source-address net_192.168.10.0/24;
destination-address net_192.168.40.0/24;
application junos-ssh;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
}
from-zone untrust to-zone trust {
policy SERVER_ACCESS_OUT {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.97.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_OUT_2 {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.50.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
policy SERVER_ACCESS_OUT_3 {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.10.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
SRX Policy notes.
1) Because we are the receiving end we need policies in both directions.
As you can see we have logging on all the rules, however looking in our logs (not shown) we see that only the SERVER_ACCESS_IN rules get matches so you might think you only need those rules. No. You need the SERVER_ACCESS_OUT rules too.
If you remove the SERVER_ACCESS_IN rule but leave the SERVER_ACCESS_OUT rule, phase 2 will come up but the SSH session will not work
If you remove the SERVER_ACCESS_OUT rule but leave the SERVER_ACCESS_IN rule then the SSH connection will not work and phase 2 will not come up.
So what can we discern from this.
SERVER_ACCESS_OUT..
This rule is the opposite of the Checkpoint rule and so is used to negotiate phase 2 identities. In our case its being used for return traffic so we need to say application 'any'.
SERVER_ACCESS_IN..
Needed as the connection is coming from this direction (Into the Trust interface) and so we can use this policy to control the allowed application(s) if we wanted to, in the same way the Checkpoint policy is limiting the connections over the VPN to SSH only.
2) Pair-Policy
You may have come across this feature used to link 2 policies together to allow for a bi-directional VPN. In our case we are only initiating from one side so its not necessary
The below link describes really well why it may be needed..
http://www.juniper.net/techpubs/software/junos-security/junos-security96/junos-security-cli-reference/jd0e75583.html
Checkpoint Policy notes.
As we are initiating the connection through the Checkpoint and as no connections will be initiated back to us we simply write the rule in the direction shown.
4) CONFIRM VPN OPERATION
a) Checkpoint side
Phase 1 confirmation message from tracker
Phase 2 confirmation message from tracker. You will get one of these for each policy pair. Here just showing for 192.168.10.0 and 192.168.40.0.
The below shows the traffic being encrypted from each of the 3 subnets.
Phase 1 and 2 SAs from VPN TU in expert mode.
Peer 10.222.222.26:
1. IKE SA <20f0d41f9ad4c331 data-blogger-escaped-aaaeb145f450b48d="">:
1. IKE SA <20f0d41f9ad4c331 data-blogger-escaped-aaaeb145f450b48d="">:
Peer 10.222.222.26:
1. SPI's related to IKE SA <20f0d41f9ad4c331 data-blogger-escaped-aaaeb145f450b48d="">:
INBOUND:
1. 0xc460d52c
2. 0xd8d980f1
3. 0xf709262f
OUTBOUND:
1. 0x93dc96d3
2. 0x5696bd7a
3. 0x153b08db
1. SPI's related to IKE SA <20f0d41f9ad4c331 data-blogger-escaped-aaaeb145f450b48d="">:
INBOUND:
1. 0xc460d52c
2. 0xd8d980f1
3. 0xf709262f
OUTBOUND:
1. 0x93dc96d3
2. 0x5696bd7a
3. 0x153b08db
I.e we have 3 pairs of IPSEC SAs which is as expected.
b) SRX side
Confirm phase 1
user@SRX> show security ike security-associations
Index State Initiator cookie Responder cookie Mode Remote Address
7791634 UP 20f0d41f9ad4c331 aaaeb145f450b48d Main 10.1.1.1
Index State Initiator cookie Responder cookie Mode Remote Address
7791634 UP 20f0d41f9ad4c331 aaaeb145f450b48d Main 10.1.1.1
user@SRX> show security ike security-associations detail
IKE peer 10.1.1.1, Index 7791634, Gateway Name: corp-gw
Role: Responder, State: UP
Initiator cookie: 20f0d41f9ad4c331, Responder cookie: aaaeb145f450b48d
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 10.222.222.26:500, Remote: 10.1.1.1:500
Lifetime: Expires in 85399 seconds
Peer ike-id: 10.1.1.1
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha1-96
Encryption : aes256-cbc
Pseudo random function: hmac-sha1
Diffie-Hellman group : DH-group-2
Traffic statistics:
Input bytes : 1880
Output bytes : 1436
Input packets: 15
Output packets: 6
Flags: IKE SA is created
IPSec security associations: 3 created, 0 deleted
Phase 2 negotiations in progress: 0
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 10.222.222.26:500, Remote: 10.1.1.1:500
Local identity: 10.222.222.26
Remote identity: 10.1.1.1
Flags: IKE SA is created
IKE peer 10.1.1.1, Index 7791634, Gateway Name: corp-gw
Role: Responder, State: UP
Initiator cookie: 20f0d41f9ad4c331, Responder cookie: aaaeb145f450b48d
Exchange type: Main, Authentication method: Pre-shared-keys
Local: 10.222.222.26:500, Remote: 10.1.1.1:500
Lifetime: Expires in 85399 seconds
Peer ike-id: 10.1.1.1
Xauth assigned IP: 0.0.0.0
Algorithms:
Authentication : hmac-sha1-96
Encryption : aes256-cbc
Pseudo random function: hmac-sha1
Diffie-Hellman group : DH-group-2
Traffic statistics:
Input bytes : 1880
Output bytes : 1436
Input packets: 15
Output packets: 6
Flags: IKE SA is created
IPSec security associations: 3 created, 0 deleted
Phase 2 negotiations in progress: 0
Negotiation type: Quick mode, Role: Responder, Message ID: 0
Local: 10.222.222.26:500, Remote: 10.1.1.1:500
Local identity: 10.222.222.26
Remote identity: 10.1.1.1
Flags: IKE SA is created
Confirm phase 2
user@SRX> show security ipsec security-associations
Total active tunnels: 3
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<6 ESP:aes-cbc-256/sha1 153b08db 2788/ unlim - root 500 10.1.1.1
>6 ESP:aes-cbc-256/sha1 f709262f 2788/ unlim - root 500 10.1.1.1
<7 ESP:aes-cbc-256/sha1 5696bd7a 2764/ unlim - root 500 10.1.1.1
>7 ESP:aes-cbc-256/sha1 d8d980f1 2764/ unlim - root 500 10.1.1.1
<8 ESP:aes-cbc-256/sha1 93dc96d3 2760/ unlim - root 500 10.1.1.1
>8 ESP:aes-cbc-256/sha1 c460d52c 2760/ unlim - root 500 10.1.1.1
user@SRX> show security ipsec security-associations detail index 7
ID: 7 Virtual-system: root, VPN Name: corp-vpn
Local Gateway: 10.222.222.26, Remote Gateway: 10.1.1.1
Local Identity: ipv4_subnet(any:0,[0..7]=192.168.40.0/24)
Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.10.0/24)
Version: IKEv1
DF-bit: clear
Policy-name: SERVER_ACCESS_OUT_3
Port: 500, Nego#: 30, Fail#: 0, Def-Del#: 0 Flag: 600829
Tunnel Down Reason: Cleared via CLI
Direction: inbound, SPI: 5696bd7a, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2724 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2162 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: d8d980f1, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2724 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2162 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
user@SRX> show security ipsec security-associations
Total active tunnels: 3
ID Algorithm SPI Life:sec/kb Mon lsys Port Gateway
<6 ESP:aes-cbc-256/sha1 153b08db 2788/ unlim - root 500 10.1.1.1
>6 ESP:aes-cbc-256/sha1 f709262f 2788/ unlim - root 500 10.1.1.1
<7 ESP:aes-cbc-256/sha1 5696bd7a 2764/ unlim - root 500 10.1.1.1
>7 ESP:aes-cbc-256/sha1 d8d980f1 2764/ unlim - root 500 10.1.1.1
<8 ESP:aes-cbc-256/sha1 93dc96d3 2760/ unlim - root 500 10.1.1.1
>8 ESP:aes-cbc-256/sha1 c460d52c 2760/ unlim - root 500 10.1.1.1
user@SRX> show security ipsec security-associations detail index 7
ID: 7 Virtual-system: root, VPN Name: corp-vpn
Local Gateway: 10.222.222.26, Remote Gateway: 10.1.1.1
Local Identity: ipv4_subnet(any:0,[0..7]=192.168.40.0/24)
Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.10.0/24)
Version: IKEv1
DF-bit: clear
Policy-name: SERVER_ACCESS_OUT_3
Port: 500, Nego#: 30, Fail#: 0, Def-Del#: 0 Flag: 600829
Tunnel Down Reason: Cleared via CLI
Direction: inbound, SPI: 5696bd7a, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2724 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2162 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Direction: outbound, SPI: d8d980f1, AUX-SPI: 0
, VPN Monitoring: -
Hard lifetime: Expires in 2724 seconds
Lifesize Remaining: Unlimited
Soft lifetime: Expires in 2162 seconds
Mode: Tunnel(0 0), Type: dynamic, State: installed
Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (256 bits)
Anti-replay service: counter-based enabled, Replay window size: 64
Showing above phase 2 SAs for one pair which matches what is shown in the Checkpoint phase 2 confirmation message. Compare the SPIs to the Checkpoint key IDs. Also note the policy to create the phase 2 SAs was SERVER_ACCESS_OUT_3 not SERVER_ACCESS_IN_3 backing up our comments before.
Check stats..
user@SRX> show security ipsec statistics
ESP Statistics:
Encrypted bytes: 397120
Decrypted bytes: 274868
Encrypted packets: 2028
Decrypted packets: 2771
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
ESP Statistics:
Encrypted bytes: 397120
Decrypted bytes: 274868
Encrypted packets: 2028
Decrypted packets: 2771
AH Statistics:
Input bytes: 0
Output bytes: 0
Input packets: 0
Output packets: 0
Errors:
AH authentication failures: 0, Replay errors: 0
ESP authentication failures: 0, ESP decryption failures: 0
Bad headers: 0, Bad trailers: 0
5) MANAGE THE SRX OVER THE VPN
To do this we will use the junos-host zone.
Lets say we only want to manage the SRX from one IP over the VPN on the 192.168.97.0/24 network - 192.168.97.80. We note we already have rules on the Checkpoint and SRX to allow SSH from 192.168.97.0/24 to 192.168.40.0/24 - so we could make use of this.
Here is how we can restrict the access to the one IP..
a) First define the hosts needed in the access control rule
user@SRX# set security address-book global address host_192.168.97.80 192.168.97.80/32
user@SRX# set security address-book global address host_192.168.40.1 192.168.40.1/32
b) Then define the access control rule that will provide granular access to the SRX and block anyone else..
user@SRX> show configuration security policies from-zone untrust to-zone junos-host
policy srx_mgmt {
match {
source-address host_192.168.97.80;
destination-address host_192.168.40.1;
application junos-ssh;
}
then {
permit;
log {
session-init;
}
}
}
policy mgmt_deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
Note: there is no tunnel action here. So we are saying permit SSH access from the untrust zone (Because that is the zone we are dumped in after we are decrypted) to the junos-host zone and permit only for the specific address in the rule.
Note: If you make the above junos-host policy then that permitted access will be the ONLY permitted access to the SRX. So be aware of that before you use junos-host and plan accordingly. Anyway its better than using firewall filters as it provides just as much control and is consistent with the rest of the policy style configuration.
c) Have a policy for return traffic
As the SRX is on the receiving end of the SSH session to it, we need a return policy.
It so happens in this case we already have one and its works for our purposes of accessing the SRX over the VPN. Namely..
from-zone untrust to-zone trust {
policy SERVER_ACCESS_OUT {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.97.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
Now if you didn't already have an appropriate return policy you could make one like this and it would work just as well and may make more sense from a zones point of view..
from-zone junos-host to-zone trust {
policy junos_host_egress {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.97.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
}
The important thing for this to work is the source and dest IPs in the rule as they are being used for the phase 2 SAs and also that the destination zone is trust.
d) Make sure you have allowed host-inbound-traffic > system-services > ssh on the appropriate zone.
Testing
We don't catch the permitted policy srx_mgmt in the logs as the flow is actually first permitted by the policy SERVER_ACCESS_IN. However I can report it works fine when SSHing from 192.168.97.80 to 192.168.40.1.
Nov 5 16:46:51 SRX RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.97.80/43765->192.168.40.1/22 junos-ssh 192.168.97.80/43765->192.168.40.1/22 None None 6 SERVER_ACCESS_IN trust untrust 12691 N/A(N/A) vlan.0 UNKNOWN UNKNOWN UNKNOWN
To show that we are really only allowing the SSH to the SRX from the one host we now try from another host on 192.168.97.0/24 and its blocked..
Nov 5 16:37:22 SRX RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.97.50/51209->192.168.40.1/22 None 6(0) mgmt_deny untrust junos-host UNKNOWN UNKNOWN N/A(N/A) .local..0 UNKNOWN policy deny
So there we have it. Configured and verified a Checkpoint to SRX policy based site to site VPN. Easy eh!
Lets say we only want to manage the SRX from one IP over the VPN on the 192.168.97.0/24 network - 192.168.97.80. We note we already have rules on the Checkpoint and SRX to allow SSH from 192.168.97.0/24 to 192.168.40.0/24 - so we could make use of this.
Here is how we can restrict the access to the one IP..
a) First define the hosts needed in the access control rule
user@SRX# set security address-book global address host_192.168.97.80 192.168.97.80/32
user@SRX# set security address-book global address host_192.168.40.1 192.168.40.1/32
b) Then define the access control rule that will provide granular access to the SRX and block anyone else..
user@SRX> show configuration security policies from-zone untrust to-zone junos-host
policy srx_mgmt {
match {
source-address host_192.168.97.80;
destination-address host_192.168.40.1;
application junos-ssh;
}
then {
permit;
log {
session-init;
}
}
}
policy mgmt_deny {
match {
source-address any;
destination-address any;
application any;
}
then {
deny;
log {
session-init;
}
}
}
Note: there is no tunnel action here. So we are saying permit SSH access from the untrust zone (Because that is the zone we are dumped in after we are decrypted) to the junos-host zone and permit only for the specific address in the rule.
Note: If you make the above junos-host policy then that permitted access will be the ONLY permitted access to the SRX. So be aware of that before you use junos-host and plan accordingly. Anyway its better than using firewall filters as it provides just as much control and is consistent with the rest of the policy style configuration.
c) Have a policy for return traffic
As the SRX is on the receiving end of the SSH session to it, we need a return policy.
It so happens in this case we already have one and its works for our purposes of accessing the SRX over the VPN. Namely..
from-zone untrust to-zone trust {
policy SERVER_ACCESS_OUT {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.97.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
Now if you didn't already have an appropriate return policy you could make one like this and it would work just as well and may make more sense from a zones point of view..
from-zone junos-host to-zone trust {
policy junos_host_egress {
match {
source-address net_192.168.40.0/24;
destination-address net_192.168.97.0/24;
application any;
}
then {
permit {
tunnel {
ipsec-vpn corp-vpn;
}
}
log {
session-init;
}
}
}
}
The important thing for this to work is the source and dest IPs in the rule as they are being used for the phase 2 SAs and also that the destination zone is trust.
d) Make sure you have allowed host-inbound-traffic > system-services > ssh on the appropriate zone.
Testing
We don't catch the permitted policy srx_mgmt in the logs as the flow is actually first permitted by the policy SERVER_ACCESS_IN. However I can report it works fine when SSHing from 192.168.97.80 to 192.168.40.1.
Nov 5 16:46:51 SRX RT_FLOW: RT_FLOW_SESSION_CREATE: session created 192.168.97.80/43765->192.168.40.1/22 junos-ssh 192.168.97.80/43765->192.168.40.1/22 None None 6 SERVER_ACCESS_IN trust untrust 12691 N/A(N/A) vlan.0 UNKNOWN UNKNOWN UNKNOWN
To show that we are really only allowing the SSH to the SRX from the one host we now try from another host on 192.168.97.0/24 and its blocked..
Nov 5 16:37:22 SRX RT_FLOW: RT_FLOW_SESSION_DENY: session denied 192.168.97.50/51209->192.168.40.1/22 None 6(0) mgmt_deny untrust junos-host UNKNOWN UNKNOWN N/A(N/A) .local..0 UNKNOWN policy deny
So there we have it. Configured and verified a Checkpoint to SRX policy based site to site VPN. Easy eh!
No comments:
New comments are not allowed.