When considering Securing FortiGate remote administration, I’ve written about changing the https management port to something other than TCP 443 before, I suppose that’s security by obfuscation (though even a script kiddy with one hours experience, will be able to spot an html responses). Typically with other vendors you limit remote administration access, to specific IP addresses (or ranges). So how to do the same in Fortigate?
FortiGate Trusted Hosts
With FortiGate the approach is slightly different, (to Cisco anyway) in that, you allow access from ‘Trusted Hosts‘ and you do that ‘Per Administrator’ not for the entire remote access solution (like HTTPS or SSH). On reflection I like this, because by default you will have a user called ‘admin’ and an attacker will ‘possibly’ know that. With FortiGate you can restrict the admin account so it can only log on from inside, or from management hosts/networks or from an Out of Band management network.
You can also give an administrative password to one partner and only allow access from that partner’s public IP/Range, or if like my firm we need to support a lot of firewalls we can hard code this into our default deployments and retain remote administration. (Though FortiManager is the direction you want to be headed in, for that!)
System > Administrators > Create New > Administrator.
Create a username/password > Select the admin level required > Enable ‘Restrict Login to Trusted Hosts’
Here’s an example where the admin account can only manage the firewall form the 192.168.1.0/24 network, and a management host 192.168.2100.3 For ‘external‘ access I’ve got a new administrator, who can get access from my management host, (for belt and braces), a single public network, and a public IP address.
Related Articles, References, Credits, or External Links
The one reason I prefer Cisco over Microsoft is they rarely change things, you learn how to do something and it’s learned. This is the second time have had to write this article purely because the Azure UI has changed!
Virtual Network Gateway Options
With VPN’s into Azure you connect to a Virtual Network Gateway, of which there are TWO types Policy Based, and Route Based. This article will deal with Policy Based, for the more modern Route based option, see the following link;
These came first, essentially they work like this, “If traffic is destined for remote network (x) then send the traffic ‘encrypted’ to local security gateway (y).” Note: Where Local Security Gateway is a firewall at YOUR site, NOT in Azure! This is the way traditionally VPNs have been done in Cisco ASA, In Cisco Firewall speak it’s the same as “If traffic matches the interesting traffic ACL, then send the traffic ‘encrypted’ to the IP address specified in the crypto map”.
Advantages:
Can be used on older Cisco Firewalls (ASA 5505, 5510, 5520, 5550, 5585).
Can be used on newer Cisco Firewalls (ASA 5506-x, 5508-X, 5512-x, 5515-x, 5516-x, 5525-X, 5545-X, 5555-x, 5585-X)
Can be used with Cisco ASA OS (pre 8.4) IKEv1 only,
Disadvantages
Can only be used for ONE connection from your Azure Subnet to your local subnet. Note: You could ‘hairpin’ multiple sites over this one tunnel, but that’s not ideal.
Route Based
These were typically used with routers, because routers use Virtual Tunnel Interfaces to terminate VPN tunnels, that way traffic can be routed down various different tunnels based on a destination, (which can be looked up in a routing table). But Cisco ASA now supports Virtual Tunnels Interfaces (After version 9.7(1))
Advantages
Can be used for VPNs to multiple sites.
Disadvantages
Requires Cisco ASA OS 9.7(1) So no ASA 5505, 5510, 5520, 5550, 5585 firewalls can use this.
Configure Azure for ‘Policy Based’ IPSec Site to Site VPN
You may already have Resource Groups and Virtual Networks setup, if so you can skip the first few steps.
Sign int0 Azure > All Services > Resource Groups > Create Resource Group > Give your Resource Group a name, and select a location > Create.
OK, if you’re used to networking this can be a little confusing, we are going to create a virtual network, and in it we are going to put a virtual subnet, (yes I know this is odd, bear with me!) It’s the ‘Subnet Name‘and ‘address range‘ that things will actually connect to, (10.0.0.0/24).
All Services > Virtual Networks > Create Virtual Network > Give the Virtual Network a name, a subnet, select your resource group > Then create a Subnet, give it a name and a subnet > Create.
To further confuse all the network engineers, we now need to add another subnet, this one will be used by the ‘gateway’. If you are a ‘networking type’ it’s part of the virtual network, but is more specific than the subnet you already created.
With your virtual network selected >Subnets > +Gateway Subnet.
You can’t change the name, (you could before, then it wouldn’t work, which was strange, but I suppose it’s fixed now) > put in another network that’s part of the Virtual-Network, but does not overlap with the subnet you created in the previous step > OK.
All Services > Virtual Network Gateways > Create Virtual Network Gateway > Name it > Policy Based (Note: This will change the SKU to Basic) > Create New Public IP > Give it a Name > Create.
Note: This will take a while, go and put the kettle on! Make sure all running tasks and deployments are complete before continuing.
You can do the next two steps together, but I prefer to do then separately, or it will error if the first one does not complete!
Now you need to create a Local Security Gateway. (To represent your Cisco ASA). All Services > Local Security Gateway > Create Local Security Gateway > Name it > Supply the public IP > Supply the Subnet(s) ‘behind’ the ASA > Select your Resource Group > Create.
Finally create the VPN > Select your Virtual Network Gateway > Connections > Add.
Give the tunnel a name > Site-to-Site IPSec > Select your Local Network Gateway (ASA) > Create a pre-shared-key (you will need this for the ASA config!) > Select your Resource Group > OK.
Configure the Cisco ASA for ‘Policy Based’ Azure VPN
I read somewhere that the ASA had to be at 9.1? That’s not true, I’ve done it with a firewall running 8.3, and I’ve read blog posts from people who have done this with a Cisco PIX (running version 6). But the firewall does have to support AES encryption (‘show version’ will tell you). There are some subtle differences in the code which I will point out below, but essentially you should be running an OS newer than 8.4 for this config to work. (As I’ve said I’ll address 8.4, and 8.3 (or earlier) below).
Connect to the ASA and create an object group for your local subnet, and the subnet that you are using in Azure, (Called Azure-SN above).
[box]
Type help or '?' for a list of available commands.
Petes-ASA> enable
Password: ********
Petes-ASA# configure terminal
Petes-ASA(config)# object-group network OBJ-AZURE-SN
Petes-ASA(config-network-object-group)# description Azure Subnet
Petes-ASA(config-network-object-group)# network-object 10.0.0.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
Petes-ASA(config)# object-group network OBJ-LOCAL-SN
Petes-ASA(config-network-object-group)# description Local Subnet
Petes-ASA(config-network-object-group)# network-object 192.168.100.0 255.255.255.0
Petes-ASA(config-network-object-group)# exit
[/box]
Then create an access-list, this will alert the firewall that there is some ‘interesting traffic’ that needs to be encrypted (we will call this ACL later on, from the crypto-map). Then create a NAT rule that stops traffic that’s going over the VPN tunnel from being NATTED.
Our VPN is going to use a pre-shared-key, (you created in Azure above). It will use AES-256 for encryption, SHA for hashing, and Diffie Hellman version 2 for key exchange. So we need to have a matching ‘phase 1’ (that’s ISAKMP) policy.
Enable ISAKMP (version 1) on the outside interface, then configure the parameters that will be used in ‘phase 2’ (that’s IPSEC). Note: If your outside interface is called something else like Outside or WAN substitute that!
Next, you need a tunnel-group, in this case the only job of the tunnel group has is to keep the pre-shared-key (PSK) to the peer you specify. Which in this case is the Azure Gateway.
The thing that ties it all together is the crypto map. Here I’ve called it “AZURE-CRYPTO-MAP”, WARNING if you already have a crypto map, use the name of that one, or all your existing VPNS will stop working, (show run crypto will tell you). This is because, you can only have one crypto map applied to an interface, but you can have many crypto map numbers, i.e crypto map {NAME} {NUMBER} {COMMAND}. And each VPN tunnel has its own number.
There are a couple of extra commands you will need, these are sysops commands. Their purpose set things globally, and are generally hidden from the config, (i.e ‘show run’ wont show them). These are recommendations from Azure. The first one drops the maximum segment size to 1350.The second command keeps the TCP session information even if the VPN tunnel drops.
To test we usually use ‘ping’, the problem with that is, if you are using Windows Servers they will have their Windows firewall on by default, which blocks pings, (bear this in mind when testing). Also your ASA needs to be setup to allow pings, (try pinging 8.8.8.8 that usually responds), if yours doesn’t then configure your ASA to allow ping traffic.
As mentioned above, you might want to turn the firewalls off to test.
On the Cisco ASA you can see the tunnel is established at Phase 1 (ISAKMP)
[box]
Petes-ASA# show cry isa
IKEv1 SAs:
Active SA: 1
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 1
1 IKE Peer: 40.113.16.195
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE
[/box]
If yours says something else, (or nothing at all) then phase 1 has not established. You need to Troubleshoot phase 1 of the VPN tunnel. (Probably: Public IP is wrong, or pre-shared-key (shared secret) has been mistyped, check these first).
Assuming that’s working, your next test is to make sure that Phase 2 has established. You should see packets encrypting and decrypting.
[box]
Petes-ASA(config)# show cry ipsec sa
interface: outside
Crypto map tag: AZURE-CRYPTO-MAP, seq num: 1, local addr: 128.65.98.43
access-list ACL-AZURE-VPN extended permit ip 192.168.100.0 255.255.255.0 10.0.0.0 255.255.255.0
local ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/0/0)
current_peer: 40.113.16.195
#pkts encaps: 2, #pkts encrypt: 2, #pkts digest: 2
#pkts decaps: 3, #pkts decrypt: 3, #pkts verify: 3
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 2, #pkts comp failed: 0, #pkts decomp failed: 0
#pre-frag successes: 0, #pre-frag failures: 0, #fragments created: 0
#PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0
#TFC rcvd: 0, #TFC sent: 0
#Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0
#send errors: 0, #recv errors: 0
local crypto endpt.: 128.65.98.43/0, remote crypto endpt.: 40.113.16.195/0
path mtu 1500, ipsec overhead 74(44), media mtu 1500
PMTU time remaining (sec): 0, DF policy: copy-df
ICMP error validation: disabled, TFC packets: disabled
current outbound spi: 97624DA8
current inbound spi : D7705547
inbound esp sas:
spi: 0xD7705547 (3614463303)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x0000000F
outbound esp sas:
spi: 0x97624DA8 (2539802024)
transform: esp-aes-256 esp-sha-hmac no compression
in use settings ={L2L, Tunnel, IKEv1, }
slot: 0, conn_id: 335872, crypto-map: AZURE-CRYPTO-MAP
sa timing: remaining key lifetime (kB/sec): (97199999/3556)
IV size: 16 bytes
replay detection support: Y
Anti replay bitmap:
0x00000000 0x00000001
Petes-ASA(config)#
[/box] If phase 2 did not connect, then you need to troubleshoot phase 2 of the VPN tunnel. (Probably: Transform set is wrong, or routing being the ASA is not working).
Azure to Cisco VPN ‘Policy Based’ IKEv1 Complete Code Snippets to Copy and Paste
(Change the values highlighted in red)WARNING: re-read the warning about crypto map names above! [box]
I’ve seen this pop up a few times in forums, and I’ve even seen people post “It cant be done, you will need to change one of the subnets,” but to be honest, it’s not that difficult.
We simply have to do some NAT. This is the bit people struggle with, with VPNs usually we need to STOP NAT being applied to VPN traffic, and we still do, we simply NAT the traffic before we sent it over the tunnel.
Normally overlapping networks can trip you up, in one of TWO scenarios;
Scenario 1 (The other end overlaps with YOU)
Scenario 2 (Two endpoints overlap with EACH OTHER)
Solution
Scenario 1 (The other end overlaps with YOU)
Firstly you need to pick another subnet for BOTH ends, and this is the subnet the other end will THINK it’s talking to, sometimes this is called an XLATED subnet, or a PSEUDO subnet, or a MASQUERADE subnet.
ASA-1 Config
Firstly we need THREE objects creating, (instead of the usual TWO). Then take note the syntax of the NAT statement;
Note: Above, I’m assuming your interfaces are called inside and outside!
Now you need to create the ACL that will be used to define ‘interesting traffic’, i.e. traffic that will be encrypted, but unlike normal you will specify the XLATED addresses.
[box]
!
access-list VPN-INTERESTING-TRAFFIC line 1 extended permit ip object OBJ-Site-A-XLATE object OBJ-Site-B-XLATE
!
[/box]
The rest of the VPN config is the same as normal, here I’m using IKEv2. If you have to use IKEv1 see the link at the bottom of the page.
WARNING: If you already have VPNs then change CRYPTO-MAP (above) to the name of your existing crypto map.
Scenario 2 (Two endpoints overlap with EACH OTHER)
Firstly you need to pick another subnet for BOTH of the ends with the overlapping subnet, and this is the subnet that your end will THINK it’s talking to, sometimes this is called an XLATED subnet, or a PSEUDO subnet, or a MASQUERADE subnet.
Then you will need to create TWO more, for the remote ends to TALK BACK TO.
Note: If you already have a VPN to one of the sites, then this process will replace that, and create one for the second site. So If you already have one tunnel you are going to need to either REMOVE it or change the NAT and Interesting traffic ACL. (Note: If you delete the ACL used by a crypto map, then it disapears from the crypto map! So you need to manually add it back). From this point forward I will assume we are creating BOTH tunnels from scratch.
ASA-1 Config
We need four objects for each XLATE, and two objects for the actual endpoints, (as two sites have the same REAL subnet we can use the same object for both). Then we create the NAT statements for each tunnel.
Now you need to create the ACL that will be used to define ‘interesting traffic’, i.e. traffic that will be encrypted. But unlike normal you will specify the XLATED addresses.
[box]
!
access-list VPN-2-Site-B extended permit ip object OBJ-Site-A-B-XLATE object OBJ-Site-B-and-C
access-list VPN-2-Site-C extended permit ip object OBJ-Site-A-C-XLATE object OBJ-Site-B-and-C
!
[/box]
The rest of the VPN config is the same as normal, here I’m using IKEv2. If you have to use IKEv1 see the link at the bottom of the page.
WARNING: If you already have VPNs then change CRYPTO-MAP (above) to the name of your existing crypto map.
ASA-2 Config
Unusually, the remote end (sometimes referred to as a ‘spoke’) does not need to be a mirror image of the main site, this is because we are sending VPN traffic ‘back’ from 192.168.1.0/24, to the XLATED subnet 10.1.1.0/24.
WARNING: If you already have VPNs then change CRYPTO-MAP (above) to the name of your existing crypto map.
ASA-3 Config
Unusually the remote end (sometimes referred to as a ‘spoke’) does not need to be a mirror image of the main site, this is because we are sending VPN traffic ‘back’ from 192.168.1.0/24, to the XLATED subnet 10.1.2.0/24.
I know BT are now shipping the BT Business Hub, to their business ADSL clients, but there’s still a few 2Wire routers out there in the wild. Essentially if you have a range of public IP addresses, this is how to allocate one of the public IP addresses to one of your devices. In my case its a Cisco ASA firewall that I need to have a public IP.
Solution
Firstly I’m going to assume the router is working and connected to the internet, if there’s a problem and you need to reset it you will need the following pieces of information.
1. The BT ADSL Username and password.
2. The public IP address range allocated to you by BT (and the IP allocated to the router).
Note: Plug your device into the router before you start, and set it to get its address via DHCP.
1. Connect to the web interface of the 2Wire router (normally http://192.168.1.254) > Settings > Broadband > Link Configuration > Scroll down the page.
2. Locate the ‘Add additional network’ section > Add in the IP address that BT have told you to allocate to the router, the subnet mask will be provided by BT also, but you can work it out with my subnet calculator if you don’t know > Save >Enter the router password if prompted.
Note: By default the password will be the Serial Number of the router, (on the white sticker). If you have forgotten you can reset it.
3. Select the LAN tab > NAT & Address Allocation > Locate your device > Set the firewall to disabled > Address Assignment = Public (Select WAN IP Mapping) > WAN IP Mapping = Public Fixed {The IP address you want to assign} > Save > Enter the password if prompted.
4. This relies on the router providing DHCP, which it will do by default, though you can check on the Private Network tab.
5. Finally either reboot the device you are assigning the IP address to, (or ‘reload’ if it’s a Cisco ASA).
Related Articles, References, Credits, or External Links
I was asked yesterday, “When you get five minutes, I need split tunneling setup, when I VPN into a network I lose Internet connectivity”. On inspection he was using the Microsoft VPN client, I jumped on the VPN device to discover it was a Cisco IOS router.
What I discovered was, unlike the firewall VPN’s I’m used to, you DONT set split tunneling up on the VPN device, you set it up on the client, (and its a bit clunky – sorry!)
Solution
1. Windows Key + R > ncpa.cpl {Enter} > Locate the VPN connection > Right Click > Properties > Networking > Internet Protocol Version 4 (TCP/IPv4) > Properties > Advanced.
2. Untick “Use default gateway on remote network” > OK > OK > OK.
BE AWARE: There is a downside to doing this, as site visitor Clayton Webb points out;
“Unchecking that default gateway is a godsend, until end users use their laptops for torrents, malware, etc. If you have the time I’d recommend a direct access setup for company equipment. VPN w/ NPS health validators for non-company equipment.”
I agree, I would only ever see this as a temporary solution for the ‘technically savvy’.
3. WARNING: At this point you may find you can connect to the VPN, and your Internet now works, (hooray!) But you can no longer talk to any servers or systems on the site you are VPN’d into. This is a Windows routing problem, lets take a look at what IP address I’m getting from the VPN Device.
Above you can see Ive got an IP address of 192.168.2.207, and in my case I don’t have a default gateway (this is not unusual, yours may be the same or you may have a default gateway as well).
4. If you open a command window and issue a ‘route print’ command, you can see the reason I don’t have a default gateway is my gateway is may actual IP address (again this is not unusual, In my case I need to remember 192.168.2.207, if you have a different gateway listed thats the one you need to take notice of).
Note: -P Adds the route persistently (will remain after a reboot). The network you are trying to get to will probably be a different network, to the network IP you are being leased to you by the VPN device. If you have multiple networks you will need a ‘route add’ for each one.
6. To demonstrate; below I can’t get to 192.168.1.1, I then enter the ‘route add’ command, and after that I can get to 192.168.1.1.
Note: I’m not adding my route as persistent!
Related Articles, References, Credits, or External Links
Having the ability to remotely administer network devices, means I don’t have to get my lazy carcass out of my chair and start fishing console cables out of my bag, also it saves on shoe leather, and travelling time.
Solution
Cisco Router / Switch – Setup Telnet Access
These days people frown at Telnet. It’s an insecure protocol so your password is sent in clear text over the wire, and can be seen by anyone sniffing traffic. For that reason SSH is preferred, but for completeness I’ll start with Telnet.
1. Log in the the device > Go to enable mode > Go to configuration mode > Enable Telnet and set a password.
[box]
Router0>enable
Router0#conf terminal
Enter configuration commands, one per line. End with CNTL/Z.
Router0(config)#line vty 0 4
Router0(config-line)#transport input telnet
Router0(config-line)# password P@ssword123
[/box]
2. Save the changes and test.
[box]
Router0(config)#exit
Router0#write mem
Building configuration...
[OK]
Router0#
[/box]
Cisco Router / Switch – Setup SSH Access
1. SSH is a little more involved, before you can connect via SSH, you need a certificate, and before you can generate a certificate, you need a host name and a domain name.
[box]
Router0>enable
Router0#conf terminal
Router0(config)#hostname Petes-Router
Petes-Router(config)#ip domain-name petenetlive.com
Petes-Router(config)#crypto key generate rsa modulus 2048
The name for the keys will be: Petes-Router@petenetlive.com
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 17 seconds)
Petes-Router(config)#
[/box]
2. Another prerequisite is you need usernames and passwords, these can be managed by a separate AAA solution like RADIUS, TACACS+, or Active Directory. But for this example I’ll simply set them up on the device, and use local authentication.
Note: I set myself up with privilege 15, this means when I log on, I automatically log on at enable mode, the other user account does not, and needs to know the enable password to make any changes.
3. Finally allow remote management via SSH, and save the changes.
[box]
Petes-Router(config)#line vty 0 4
Petes-Router(config-line)#transport input ssh
Petes-Router(config-line)#exit
Petes-Router(config)#exit
Petes-Router#write mem
Building configuration...
[OK]
Petes-Router#
[/box]
4.Finally you need to enable AAA Authentication to use the local database;
[box]
Petes-Router(config)#aaa new-model
Petes-Router(config)#aaa authentication login default local
Petes-Router(config)#aaa authorization exec default local
[/box]
WARNING
This also will enable username/password authentication for ‘console‘ (rollover cable) access. I dont like that, so I remove that with the following commands;
Cisco Router – Restricting Telnet and SSH Access via Access List
You can lock down access further to remote management, by allowing or denying access from an ACL.
WARNING: If doing this remotely, and just using SSH remember to generate the key and create users FIRST, or you may lock yourself out. If you are worried schedule a reload in twenty minutes, do the work, if it works cancel the reload, if it all explodes, go have a coffee, when you come back it will have reverted back!
Schedule a Router Reload
[box]
Petes-Router#reload in 20
Reload scheduled in 20 minutes by petelong on vty0 (123.123.123.123)
Reload reason: Reload Command
Proceed with reload? [confirm] {Enter}
Petes-Router#
---CARRY OUT THE CHANGES---
Petes-Router#reload cancel
Petes-Router#
***
*** --- SHUTDOWN ABORTED ---
***
[/box]
1. From the top let’s create a user, and setup the RSA key, (skip this step if you have already done this).
[box]
Router0>enable
Router0#conf terminal
Router0(config)#hostname Petes-Router
Petes-Router(config)#ip domain-name petenetlive.com
Petes-Router(config)#crypto key generate rsa modulus 2048
The name for the keys will be: Petes-Router@petenetlive.com
% The key modulus size is 2048 bits
% Generating 2048 bit RSA keys, keys will be non-exportable...
[OK] (elapsed time was 17 seconds)
Petes-Router(config)#
[/box]
2. Now create an access-list to allow and deny access, (usual ACL rules apply).
Petes-Router(config)#ip access-list extended VTY_ACCESS
Petes-Router(config-ext-nacl)#10 permit tcp 123.123.123.123 0.0.0.0 any eq 23
Petes-Router(config-ext-nacl)#20 permit tcp 123.123.123.123 0.0.0.0 any eq 22
Petes-Router(config-ext-nacl)#30 permit tcp 10.1.1.0 0.0.0.255 any eq 23
Petes-Router(config-ext-nacl)#100 deny ip any any
Petes-Router(config-ext-nacl)#exit
Petes-Router(config)#
[/box]
2. In this example I will set the transport input to all (that’s TelnetANDSSH), then lock access down the the ACL we have just created.
[box]
Petes-Router(config)#line vty 0 4
Petes-Router(config-line)#transport input all
Petes-Router(config-line)#login local
Petes-Router(config-line)#access-class VTY_ACCESS in
Petes-Router(config-line)#exit
Petes-Router(config)#exit
[/box]
3. Save your changes and test.
[box]
Petes-Router#write mem
Building configuration...
[OK]
Petes-Router#
[/box]
Related Articles, References, Credits, or External Links
You want to establish a site to site VPN from a site with a Cisco ASA firewall, to another site running a Juniper SRX firewall. I had to do this this week, and struggled to find any good information to help.
In the example below I’m configuring the whole thing from a laptop (172.16.254.206) that’s on the Juniper’s site. Use the diagram below, and substitute your own IP addresses and subnet addresses, to get a workable solution for your site.
When the process is complete, I will test it by pinging the host behind the Cisco ASA on the remote site (10.254.254.5).
Solution
Before you begin, I will assume both firewalls are functioning properly and the clients behind them can access internet services (where allowed) through them already.
5. Enter the Local (behind the ASA) network > Then the Remote (behind the Juniper) network > Next.
Note: You can type them in, but if you use the pick-list button you can select ‘inside-network’ for the local, and define a network object for the remote network.
6. Enter a pre shared key, (remember this, you need to enter it on the Juniper).
8. Enable PFS > Tick the box to exempt traffic from NAT > Next.
9. Review the settings > Finish
11. Save the changes > File > Save running Configuration to Flash.
Step 2 – Configure the Juniper SRX (Route Based VPN)
Model used SRX100B version 11.2R4.3
The SRX support two types of VPN
Route based VPN – VPN selection is done based on the route. In this you define a route pointing to the tunnel interface (st0 interface) bound to the VPN.
Policy based VPN – VPN is selected based on the policy.
15. Give the tunnel a name > Set the local zone to trust > Add in the local subnet (behind the Juniper) > Name the Secure Tunnel Interface (just put in a zero) > Set the secure tunnel zone to Untrust > Enter the physical address the VPN will be terminating on, (usually the fe0/0/0.0 interface, but it does not have to be) > Next.
Note: On the Juniper, when specifying a subnet use the short subnet notation, i.e. 192.168.1.0 255.255.255.0 would be 192.168.1.0/24 (if you get stuck use my subnet calculator).
16. Supply the public IP address of the ASA > and add in the subnet at the far end of the tunnel (behind the ASA) > Next.
17. Set the IKE (phase 1) settings to Compatible, Main Mode, enter the same pre shared key you setup in Step 1 (number 6) > Set the IPSEC (phase 2) settings to Compatible, IPsec Perfect Forward Secrecy (PFS) to group 2 > Next.
20. Navigate to IPsecVPN > Auto Tunnel > Phase II > Select your tunnel > Edit > IPsecVPN Options > Tick ‘use proxy identity’ > Enter the local and remote subnets > OK.
21. Navigate to Security > Zones/Screen > Select the untrust zone > Edit > Host Inbound traffic – Interface > Select the physical address that the VPN is terminating on (usually fe-0/0/0.0) > Add IKE as an Interface service > OK.
22. To save the changes > Action > Commit.
23. Test the VPN by attempting to ping a host on the other end.
Juniper SRX Command Line
On the Cisco firewalls I prefer to work at command line. The Juniper Firewall also supports CLI, you can check the VPN config with the following commands;
If you want you can execute the below commands on CLI to get the “set” commands
show security ike | display set
show security ipsec | display set
show | display set | match <external interface configured in ike>
show | display set | match <st.x>
Above commands will give you the “set” commands for cli.
Related Articles, References, Credits, or External Links
Special thanks to Kalanidhi Tripathi at JTAC for his assistance.
