Juniper tincture: Prepare Juniper SRX. Part 2: IPSec
Not so long ago, we felt a little Juniper SRX, set it up , and put together a failover cluster. Now we will begin to raise on it “combat” schemes, for the sake of which everything was started.
For example, let's mentally compile the following scheme:
In the diagram we can see the central office and the node connected to it - this can be either a branch or a remote customer / client, which requires a secure connection to communicate with. Of course, there may be several of them (see below). At the same time, the method of communication is absolutely not important for us: at least the Internet, even the “dark fiber” - the data still needs to be encrypted in order to minimize the risk of their leakage. And the higher the cipher strength and the more perfect the filtering method, the more completely the nerves of the administrator will be (as you probably know, a sysadmin, like any closed system, always strives for a state of rest).
')
The main difference between ipsec and the same encrypted ovpn or pptp is a much higher degree of resistance to cracking, as well as a much wider degree of unification and prevalence. It is much easier to connect two site-to-site pieces of iron if you need an encrypted channel using ipsec than raising a ppp connection between them. Because ipsec can do almost all routers are smarter than a home soap dish (there are special VPN gateways), but with ppp connections, nuances are always possible. And to connect remote employees, you can use a combination of these solutions, such as Cisco Anyconnect or L2tp / ipsec - with their help you can create a secure connection directly from the client device, and not from the router.
The process of establishing a secure tunnel consists of two phases: first, the devices “recognize” each other using IKE and agree on the type of encryption used, integrity monitoring and authentication, and then proceed to the second phase.
In the second stage, the main tunnel is built for the data (the connection raised in the first phase is used to update the SA).
More information about IPSec can be found, for example, in the seventh edition of SDSM, but we will practice.
IPSec VPN (in our case, we only consider the site-to-site tunnel mode) in Juniper SRX are of two types: Policy based and Routed based. The differences between them can be read in the official Juniper KB in English.
I will use in my example my HA-pair Juniper SRX, about which you can read here . There is also a configuration of interfaces (interfaces are also signed on the diagram).
1. Policy based VPN
The easiest way to configure, and need, when, for example, you want to connect two networks with each other. At the same time, there is no overlapping of networks with each other and no NAT is used.
It is configured, in general, elementary (comments in the config itself). I mean that the reader represents what IPSec is, and at least once configured it.
Such a scheme is effective, for example, to communicate with one small branch via the Internet. In this case, both networks see each other completely transparent. In general, this is an analogue of the usual cisco-like ipsec without unnecessary embellishments or complications. The noticeable difference is that there are two that need resolving policies, and not one, otherwise it will not work.
2. Route-based
Much more interesting with Route-based. In this case, a special tunnel interface is used, respectively, we are able to do NAT (dst, src, static), organize hub-and-spoke schemes, etc. The analogue is IPSec VTI and, in part, DMVPN (the implementation is hub-and-spoke, but it is not possible to compare it with DMVPN, because there isonly one SRX in HQ).
In the scheme above, we add one condition: all addresses of our locale will be translated into one. Suppose 192.168.100.100. This is usually done in order not to turn the acl on the customer’s side into a fierce footcloth.
We will assume that we can influence the remote side in an extremely limited way (change PSK or refine the parameters of the crypto tunnel, but no more).
But what if you need access to more than one server on the remote side? Each source / destination pair requires a separate vpn instance. Fortunately, only he. All other settings (policy / proposal / gateway) can be left unchanged.
Add:
Please note: the unit remains the same, we just add another vpn-tunnel to it. But if you need to build an ipsec tunnel with another client, then it would be more logical to allocate it into a separate unit.
Well, now add policy and NAT. Since st0.1 we have in a separate zone, the policy we build not in untrust, but in a VPN.
Security-policy in this form is created exclusively for tests! In the future, access should be limited in accordance with the requirements of security.
If only “one way” access is needed, then it is not necessary to create a “reverse” policy.
Apply changes:
Checking:
SA are installed, bags run, the channel works.
That's all. Good luck with your setup!
For example, let's mentally compile the following scheme:
In the diagram we can see the central office and the node connected to it - this can be either a branch or a remote customer / client, which requires a secure connection to communicate with. Of course, there may be several of them (see below). At the same time, the method of communication is absolutely not important for us: at least the Internet, even the “dark fiber” - the data still needs to be encrypted in order to minimize the risk of their leakage. And the higher the cipher strength and the more perfect the filtering method, the more completely the nerves of the administrator will be (as you probably know, a sysadmin, like any closed system, always strives for a state of rest).
')
The main difference between ipsec and the same encrypted ovpn or pptp is a much higher degree of resistance to cracking, as well as a much wider degree of unification and prevalence. It is much easier to connect two site-to-site pieces of iron if you need an encrypted channel using ipsec than raising a ppp connection between them. Because ipsec can do almost all routers are smarter than a home soap dish (there are special VPN gateways), but with ppp connections, nuances are always possible. And to connect remote employees, you can use a combination of these solutions, such as Cisco Anyconnect or L2tp / ipsec - with their help you can create a secure connection directly from the client device, and not from the router.
The process of establishing a secure tunnel consists of two phases: first, the devices “recognize” each other using IKE and agree on the type of encryption used, integrity monitoring and authentication, and then proceed to the second phase.
In the second stage, the main tunnel is built for the data (the connection raised in the first phase is used to update the SA).
More information about IPSec can be found, for example, in the seventh edition of SDSM, but we will practice.
IPSec VPN (in our case, we only consider the site-to-site tunnel mode) in Juniper SRX are of two types: Policy based and Routed based. The differences between them can be read in the official Juniper KB in English.
I will use in my example my HA-pair Juniper SRX, about which you can read here . There is also a configuration of interfaces (interfaces are also signed on the diagram).
1. Policy based VPN
The easiest way to configure, and need, when, for example, you want to connect two networks with each other. At the same time, there is no overlapping of networks with each other and no NAT is used.
It is configured, in general, elementary (comments in the config itself). I mean that the reader represents what IPSec is, and at least once configured it.
edit security address-book set global address 192.168.100.0/24 192.168.100.0/24 set global address 10.0.0.10/32 10.0.0.10/32 # phase1-proposal. # # , # Cisco, isakmp policy, proposals. # proposal top edit security ike set proposal ike_prop_1 description "ike proposal" set proposal ike_prop_1 authentication-method pre-shared-keys set proposal ike_prop_1 dh-group group5 set proposal ike_prop_1 authentication-algorithm sha1 set proposal ike_prop_1 encryption-algorithm 3des-cbc set proposal ike_prop_1 lifetime-seconds 86400 # "". proposal, # psk. # , set policy ike_policy_1 mode main set policy ike_policy_1 description "ike policy" set policy ike_policy_1 proposals ike_prop_1 # , . #, psk set policy ike_policy_1 ike pre-shared-key ascii-text XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #IKE gw . # , , gw ( ). # ike policy set gateway ike_gateway_1 ike-policy ike_policy_1 # , set gateway ike_gateway_1 address 2.2.2.2 # set gateway ike_gateway_1 dead-peer-detection interval 10 set gateway ike_gateway_1 dead-peer-detection threshold 5 # "" , . set gateway ike_gateway_1 external-interface reth2.10; # # , proposal-policy # top edit security ipsec set proposal ipsec_prop_1 description "ipsec proposal" set proposal ipsec_prop_1 protocol esp set proposal ipsec_prop_1 authentication-algorithm hmac-sha1-96 set proposal ipsec_prop_1 encryption-algorithm 3des-cbc set proposal ipsec_prop_1 lifetime-seconds 3600 set policy ipsec_policy_1 description "ipsec policy" set policy ipsec_policy_1 perfect-forward-secrecy keys group5 set policy ipsec_policy_1 proposals ipsec_prop_1; # vpn instance. , set vpn vpn_1 df-bit clear set vpn vpn_1 ike gateway ike_gateway_1 set vpn vpn_1 ike ipsec-policy ipsec_policy_1 # - , # set vpn_1 establish-tunnels on-traffic top edit security set policies from-zone trust to-zone untrust policy vpn-to-untrust match source-address 192.168.100.0/24 # , addressbook! set policies from-zone trust to-zone untrust policy vpn-to-untrust match destination-address 10.0.0.10/32 set policies from-zone trust to-zone untrust policy vpn-to-untrust match application any set policies from-zone trust to-zone untrust policy vpn-to-untrust then permit tunnel ipsec-vpn vpn_1 # "" . # set policies from-zone trust to-zone untrust then permit tunnel pair-policy vpn-from-untrust set policies from-zone untrust to-zone trust policy vpn-from-untrust match source-address 10.0.0.10/32 set policies from-zone untrust to-zone trust policy vpn-from-untrust match destination-address 192.168.100.0/24 set policies from-zone untrust to-zone trust policy vpn-from-untrust match application any set policies from-zone untrust to-zone trust policy vpn-from-untrust then permit tunnel ipsec-vpn vpn_1 set policies from-zone untrust to-zone trust policy vpn-from-untrust then permit tunnel pair-policy vpn-to-untrust Such a scheme is effective, for example, to communicate with one small branch via the Internet. In this case, both networks see each other completely transparent. In general, this is an analogue of the usual cisco-like ipsec without unnecessary embellishments or complications. The noticeable difference is that there are two that need resolving policies, and not one, otherwise it will not work.
2. Route-based
Much more interesting with Route-based. In this case, a special tunnel interface is used, respectively, we are able to do NAT (dst, src, static), organize hub-and-spoke schemes, etc. The analogue is IPSec VTI and, in part, DMVPN (the implementation is hub-and-spoke, but it is not possible to compare it with DMVPN, because there is
In the scheme above, we add one condition: all addresses of our locale will be translated into one. Suppose 192.168.100.100. This is usually done in order not to turn the acl on the customer’s side into a fierce footcloth.
We will assume that we can influence the remote side in an extremely limited way (change PSK or refine the parameters of the crypto tunnel, but no more).
edit security ike #, -, set policy ike_policy_1 mode main set policy ike_policy_1 proposals ike_prop_1 set policy ike_policy_1 pre-shared-key ascii-text "XXXXXXXXXXXX" set gateway ike_gateway_1 ike-policy ike_policy_1 set gateway ike_gateway_1 address 2.2.2.2 set gateway ike_gateway_1 dead-peer-detection always-send set gateway ike_gateway_1 external-interface reth2.10 top edit security ipsec # : bind-interface # st0 set vpn vpn_1 bind-interface st0.1 set vpn vpn_1 df-bit clear set vpn vpn_1 ike gateway ike_gateway_1 # #proxy-identity, , , ipsec acl # Cisco, , # crypto map set vpn vpn_1 ike proxy-identity local 192.168.100.100/32 set vpn vpn_1 ike proxy-identity remote 10.0.0.10/32 set vpn vpn_1 ike proxy-identity service any #proxy-identity acl , # . , # set vpn vpn_1 ike ipsec-policy ipsec_policy_1 # , set vpn supervpn establish-tunnels immediately # , #, , vpn top set interfaces st0 unit 1 description vpn_1 # "": set interfaces st0 unit 1 family inet next-hop-tunnel 172.27.1.1 ipsec-vpn vpn_1 set interfaces st0 unit 1 family inet address 172.27.1.254/24 #.. , , # host-inbound . # , , ping set security zones security-zone VPN interfaces st0.1 # "" ike set security zones security-zone INTERNET host-inbound-traffic system-services ping set security zones security-zone INTERNET host-inbound-traffic system-services traceroute set security zones security-zone INTERNET host-inbound-traffic system-services ike set security zones security-zone INTERNET interfaces reth2.10 # set routing-options static route 10.0.0.10/32 next-hop 172.27.1.1 But what if you need access to more than one server on the remote side? Each source / destination pair requires a separate vpn instance. Fortunately, only he. All other settings (policy / proposal / gateway) can be left unchanged.
Add:
#, P2MP set interfaces st0 unit 1 multipoint # set interfaces st0 unit 1 family inet next-hop-tunnel 172.27.1.2 ipsec-vpn vpn_2 set routing-options static route 10.0.0.3/32 next-hop 172.27.1.2 edit security ipsec set vpn vpn_2 bind-interface st0.1 set vpn vpn_2 df-bit clear #IKE GW set vpn vpn_2 ike gateway ike_gateway_1 set vpn vpn_2 ike proxy-identity local 192.168.100.100/32 set vpn vpn_2 ike proxy-identity remote 10.0.0.3/32 set vpn vpn_2 ike proxy-identity service any Please note: the unit remains the same, we just add another vpn-tunnel to it. But if you need to build an ipsec tunnel with another client, then it would be more logical to allocate it into a separate unit.
Well, now add policy and NAT. Since st0.1 we have in a separate zone, the policy we build not in untrust, but in a VPN.
edit security nat set source pool pool1 address 192.168.100.100/32 to 192.168.100.100/32 set source rule-set SNAT-TO-VPN from zone trust set source rule-set SNAT-TO-VPN to zone VPN set source rule-set SNAT-TO-VPN rule snat match source-address-name 192.168.100.0/24 set source rule-set SNAT-TO-VPN rule snat match destination-address-name 10.0.0.3/32 set source rule-set SNAT-TO-VPN rule snat match destination-address-name 10.0.0.10/32 set source rule-set SNAT-TO-VPN rule snat then source-nat pool pool1 Security-policy in this form is created exclusively for tests! In the future, access should be limited in accordance with the requirements of security.
edit security set policies from-zone VPN to-zone trust policy permit-all match source-address any set policies from-zone VPN to-zone trust policy permit-all match destination-address any set policies from-zone VPN to-zone trust policy permit-all match application any set policies from-zone VPN to-zone trust policy permit-all then permit If only “one way” access is needed, then it is not necessary to create a “reverse” policy.
Apply changes:
commit Checking:
show security ipsec statistics show security ike security-associations detail SA are installed, bags run, the channel works.
That's all. Good luck with your setup!
Source: https://habr.com/ru/post/230267/
All Articles