Juniper SRX: Site-to-Site IPSec VPN using pre-shared-key
In the continuation of the Juniper SRX configuration theme , I’ll bring to your attention step-by-step instructions on how to configure Site-to-Site IPSec VPN using a pre-shared-key. I draw attention to the fact that both SRX'a must have a static external IP address.
Let's start with the concept of our network:
From this diagram, it is clear that both devices are connected to the provider via the interfaces ge-0/0/0 and behind each SRX there is a private network (connected to ge-0/0/1). Our goal is to build an IPSec tunnel and allow traffic between networks 172.16.1.0/24 and 172.16.2.0/24.
')
It is assumed that the external interface receives the address via DHCP, to simplify the configuration.
All interested in asking under the cat.
I suggest first to take a look at the configuration of one of the routers BEFORE the IPSec settings, so that it is from where to repel:
The configuration of the second device is similar, except for the settings of the DHCP server and the lo0 interface. In this scenario, we are dealing with an ordinary router.
About IPSec in more detail you can read (for example) on Wikipedia .
Let's start tuning the tunnel.
To begin with, we will create a virtual interface that will be used to build the tunnel:
Since if we build a tunnel for only two devices, then the network is enough for us / 30.
Configure IKE to use IKE main mode:
Details:
pre-shared-keys authentication-method — enable pre-shared keys;
dh-group group14 - needed to generate a shared private key when exchanging data over an unprotected channel (described in detail here ), I use a 2048-bit module;
authentication-algorithm sha-256 - for authentication, we will use sha-256;
encryption-algorithm aes-128-cbc - encrypt the data in the first phase will be aes-128-cbc;
lifetime-seconds 3600 - the lifetime of the private key (it was generated automatically during connection initialization) of the first phase;
mode main - main mode
pre-shared-key ascii-text - the key itself (I recommend generating it large enough, for example, so openssl rand -base64 32 )
address 20.20.20.20 - the public address of the second SRX
external-interface ge-0/0 / 0.0 - interface through which IPSec traffic will pass.
At this stage, the IPSec tunnel itself is created.
Details:
protocol esp - we will use ESP (Encapsulated Security Payload header) (described in detail here );
authentication-algorithm hmac-sha-256-128 - IPSec authentication algorithm;
encryption-algorithm aes-128-cbc - encryption algorithm;
lifetime-seconds 7200 - the lifetime of the private key (it was generated automatically during connection initialization) of the second phase;
perfect-forward-secrecy keys group14 - similar to dh-group;
bind-interface st0.0 - virtual interface for building IPSec tunnel;
establish-tunnels immediately - create a tunnel right now.
Similar settings need to be applied on the second router (replacing the IP address with st0.0 and ike gateway).
This completes the configuration of the IPSec tunnel itself, but since SRX series is also a firewall, then with such parameters the tunnel will not rise - the firewall will drop all packets with an attempt to establish a tunnel. Therefore, we will make changes to the settings of the firewall part:
The first command allows IKE traffic on our external interface (which looks towards the provider); the second and third allow the passage of all traffic inside the IPSec tunnel.
Now the tunnel should go up, let's check it:
You can still check the old-good way:
Statistics on the use of the tunnel can be viewed as:
But that's not all! We need to register routes to the network "after another router", but because we are lazy and do not like unnecessary work (right?), then we will use OSPF:
As always, do not forget to commit (and apply symmetrical settings on the other end of the tunnel), otherwise it will not work:
Let's start with the concept of our network:
From this diagram, it is clear that both devices are connected to the provider via the interfaces ge-0/0/0 and behind each SRX there is a private network (connected to ge-0/0/1). Our goal is to build an IPSec tunnel and allow traffic between networks 172.16.1.0/24 and 172.16.2.0/24.
')
It is assumed that the external interface receives the address via DHCP, to simplify the configuration.
All interested in asking under the cat.
I suggest first to take a look at the configuration of one of the routers BEFORE the IPSec settings, so that it is from where to repel:
root @ gw-jvsrx-a # show
version 12.1X46-D10.2; system { host-name gw-jvsrx-a; root-authentication { encrypted-password "$1$XXX"; ## SECRET-DATA } services { ssh { protocol-version v2; client-alive-count-max 5; client-alive-interval 120; connection-limit 5; rate-limit 2; } dhcp { default-lease-time 21600; pool 172.16.1.0/27 { address-range low 172.16.1.2 high 172.16.1.30; router { 172.16.1.1; } propagate-settings ge-0/0/1.0; } } } ntp { server 0.pool.ntp.org prefer; server 1.pool.ntp.org; server 2.pool.ntp.org; server 3.pool.ntp.org; } } interfaces { ge-0/0/0 { unit 0 { family inet { dhcp; } } } ge-0/0/1 { unit 0 { family inet { address 172.16.1.1/27; } } } lo0 { unit 0 { family inet { address 172.31.255.1/32; } } } } security { nat { source { rule-set trust-to-untrust { from zone trust; to zone untrust; rule source-nat { match { source-address 0.0.0.0/0; } then { source-nat { interface; } } } } } } policies { from-zone trust to-zone untrust { policy trust-to-untrust { match { source-address any; destination-address any; application any; } then { permit; } } } from-zone trust to-zone trust { policy trust-to-trust { match { source-address any; destination-address any; application any; } then { permit; } } } } zones { security-zone untrust { tcp-rst; interfaces { ge-0/0/0.0 { host-inbound-traffic { system-services { dhcp; ping; ssh; } } } } } security-zone trust { interfaces { ge-0/0/1.0 { host-inbound-traffic { system-services { all; } protocols { all; } } } lo0.0 { host-inbound-traffic { system-services { ping; } } } } } } } The configuration of the second device is similar, except for the settings of the DHCP server and the lo0 interface. In this scenario, we are dealing with an ordinary router.
About IPSec in more detail you can read (for example) on Wikipedia .
Let's start tuning the tunnel.
Tunnel interface
To begin with, we will create a virtual interface that will be used to build the tunnel:
set interfaces st0 unit 0 family inet address 172.16.0.1/30 Since if we build a tunnel for only two devices, then the network is enough for us / 30.
First phase
Configure IKE to use IKE main mode:
set security ike proposal ike-proposal authentication-method pre-shared-keys set security ike proposal ike-proposal dh-group group14 set security ike proposal ike-proposal authentication-algorithm sha-256 set security ike proposal ike-proposal encryption-algorithm aes-128-cbc set security ike proposal ike-proposal lifetime-seconds 3600 set security ike policy ike-policy mode main set security ike policy ike-policy pre-shared-key ascii-text "YOUR_PRE_SHARED_KEY" set security ike policy ike-policy proposals ike-proposal set security ike gateway gw-jvsrx-b ike-policy ike-policy set security ike gateway gw-jvsrx-b address 20.20.20.20 set security ike gateway gw-jvsrx-b external-interface ge-0/0/0.0 Details:
pre-shared-keys authentication-method — enable pre-shared keys;
dh-group group14 - needed to generate a shared private key when exchanging data over an unprotected channel (described in detail here ), I use a 2048-bit module;
authentication-algorithm sha-256 - for authentication, we will use sha-256;
encryption-algorithm aes-128-cbc - encrypt the data in the first phase will be aes-128-cbc;
lifetime-seconds 3600 - the lifetime of the private key (it was generated automatically during connection initialization) of the first phase;
mode main - main mode
pre-shared-key ascii-text - the key itself (I recommend generating it large enough, for example, so openssl rand -base64 32 )
address 20.20.20.20 - the public address of the second SRX
external-interface ge-0/0 / 0.0 - interface through which IPSec traffic will pass.
Second phase
At this stage, the IPSec tunnel itself is created.
set security ipsec proposal ipsec-proposal protocol esp set security ipsec proposal ipsec-proposal authentication-algorithm hmac-sha-256-128 set security ipsec proposal ipsec-proposal encryption-algorithm aes-128-cbc set security ipsec proposal ipsec-proposal lifetime-seconds 7200 set security ipsec policy ipsec-policy perfect-forward-secrecy keys group14 set security ipsec policy ipsec-policy proposals ipsec-proposal set security ipsec vpn gw-jvsrx-b bind-interface st0.0 set security ipsec vpn gw-jvsrx-b ike gateway gw-jvsrx-b set security ipsec vpn gw-jvsrx-b ike ipsec-policy ipsec-policy set security ipsec vpn gw-jvsrx-b establish-tunnels immediately Details:
protocol esp - we will use ESP (Encapsulated Security Payload header) (described in detail here );
authentication-algorithm hmac-sha-256-128 - IPSec authentication algorithm;
encryption-algorithm aes-128-cbc - encryption algorithm;
lifetime-seconds 7200 - the lifetime of the private key (it was generated automatically during connection initialization) of the second phase;
perfect-forward-secrecy keys group14 - similar to dh-group;
bind-interface st0.0 - virtual interface for building IPSec tunnel;
establish-tunnels immediately - create a tunnel right now.
Similar settings need to be applied on the second router (replacing the IP address with st0.0 and ike gateway).
Finish line
This completes the configuration of the IPSec tunnel itself, but since SRX series is also a firewall, then with such parameters the tunnel will not rise - the firewall will drop all packets with an attempt to establish a tunnel. Therefore, we will make changes to the settings of the firewall part:
set security zones security-zone untrust interfaces ge-0/0/0.0 host-inbound-traffic system-services ike set security zones security-zone trust interfaces st0.0 host-inbound-traffic system-services all set security zones security-zone trust interfaces st0.0 host-inbound-traffic protocols all The first command allows IKE traffic on our external interface (which looks towards the provider); the second and third allow the passage of all traffic inside the IPSec tunnel.
Now the tunnel should go up, let's check it:
root@gw-jvsrx-a# run show security ike security-associations detail IKE peer 20.20.20.20, Index 2116322, Gateway Name: gw-jvsrx-b Role: Responder, State: UP Initiator cookie: 1fa7a8730c817511, Responder cookie: 2a3e1f8c554ddb85 Exchange type: Main, Authentication method: Pre-shared-keys Local: 10.10.10.10:500, Remote: 20.20.20.20:500 Lifetime: Expires in 2291 seconds Peer ike-id: 20.20.20.20 Xauth assigned IP: 0.0.0.0 Algorithms: Authentication : hmac-sha256-128 Encryption : aes128-cbc Pseudo random function: hmac-sha256 Diffie-Hellman group : DH-group-14 Traffic statistics: Input bytes : 1244 Output bytes : 948 Input packets: 6 Output packets: 4 Flags: IKE SA is created IPSec security associations: 1 created, 1 deleted Phase 2 negotiations in progress: 0 Negotiation type: Quick mode, Role: Responder, Message ID: 0 Local: 10.10.10.10:500, Remote: 20.20.20.20:500 Local identity: 10.10.10.10 Remote identity: 20.20.20.20 Flags: IKE SA is created root@gw-jvsrx-a# run show security ipsec security-associations detail ID: 131073 Virtual-system: root, VPN Name: gw-jvsrx-b Local Gateway: 10.10.10.10, Remote Gateway: 20.20.20.20 Local Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Remote Identity: ipv4_subnet(any:0,[0..7]=0.0.0.0/0) Version: IKEv1 DF-bit: clear Bind-interface: st0.0 Port: 500, Nego#: 2, Fail#: 0, Def-Del#: 0 Flag: 0x600a29 Last Tunnel Down Reason: Delete payload received Direction: inbound, SPI: ea287d13, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 5884 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 5295 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits) Anti-replay service: counter-based enabled, Replay window size: 64 Direction: outbound, SPI: 14a16181, AUX-SPI: 0 , VPN Monitoring: - Hard lifetime: Expires in 5884 seconds Lifesize Remaining: Unlimited Soft lifetime: Expires in 5295 seconds Mode: Tunnel(0 0), Type: dynamic, State: installed Protocol: ESP, Authentication: hmac-sha256-128, Encryption: aes-cbc (128 bits) Anti-replay service: counter-based enabled, Replay window size: 64 You can still check the old-good way:
root@gw-jvsrx-a# run ping 172.16.0.2 count 5 interface st0.0 PING 172.16.0.2 (172.16.0.2): 56 data bytes 64 bytes from 172.16.0.2: icmp_seq=0 ttl=64 time=14.274 ms 64 bytes from 172.16.0.2: icmp_seq=1 ttl=64 time=10.420 ms 64 bytes from 172.16.0.2: icmp_seq=2 ttl=64 time=10.448 ms 64 bytes from 172.16.0.2: icmp_seq=3 ttl=64 time=10.448 ms 64 bytes from 172.16.0.2: icmp_seq=4 ttl=64 time=10.439 ms --- 172.16.0.2 ping statistics --- 5 packets transmitted, 5 packets received, 0% packet loss round-trip min/avg/max/stddev = 10.420/11.206/14.274/1.534 ms Statistics on the use of the tunnel can be viewed as:
root@gw-jvsrx-a# run show security ipsec statistics ESP Statistics: Encrypted bytes: 85052 Decrypted bytes: 41088 Encrypted packets: 553 Decrypted packets: 512 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 But that's not all! We need to register routes to the network "after another router", but because we are lazy and do not like unnecessary work (right?), then we will use OSPF:
set protocols ospf area 0.0.0.0 interface ge-0/0/1.0 set protocols ospf area 0.0.0.0 interface st0.0 As always, do not forget to commit (and apply symmetrical settings on the other end of the tunnel), otherwise it will not work:
root@gw-jvsrx-a# commit check configuration check succeeds root@gw-jvsrx-a# commit commit complete Source: https://habr.com/ru/post/230087/
All Articles