Usually when you Telnet to an Exchange server it gives you a 220 message followed by the “Banner” of the Exchange server, a little like:
220 Servername.domainname.com Microsoft ESMTP Mail service ready at (Date/Time)
The reason why you see this happening is, there is something in between you and the Exchange server that’s stopping/filtering ESMTP traffic.
In this clients case I knew straight away what that was, (because I’d seen it before,) Cisco firewalls (PIX and ASA) that have SMTP/ESMTP inspection enabled cause this to happen.
Disable ESMTP Inspection on Cisco ASA Via command line
Note: If you send mail via TLSDO NOT do this. (see here).
2. Usually you will find ESMTP inspection enabled on the “global_policy” in the class called “inspection_default”, below are the commands to disable this feature.
I was working on an SRX100B Firewall yesterday, and needed to be able to ping the outside interface.
Solution
Note: You can quickly enable ping on a physical interface from CLI like so;
[box] set security zone security-zone trust interface ge-0/0/0 host-inbound-traffic system services ping
[/box]
1. Log into the web console of the Juniper.
2. Navigate to Security > Zones/Screen > Select the ‘Untrust’ Zone > Edit > Host inbound traffic – Interface > Under Interface services add in ‘ping’ > OK.
Note: To allow pinging of the inside interface select the trusted zone.
3. Then to save the change click Action > Commit.
Related Articles, References, Credits, or External Links
Assuming you already have web management enabled, and you want to access it from the outside (the untrusted zone).
Solution
1. Log into the web console of the Juniper.
2. Navigate to Security > Zones/Screen > Select the ‘Untrust’ Zone > Edit > Host inbound traffic – Interface > Select the Outside interface > Under Interface services add in ‘http’ > OK.
3. Then to save the change click Action > Commit.
4. Test Externally.
Related Articles, References, Credits, or External Links
Site to Site VPN’s either work faultlessly straight away, or involve head scratching and a call to Cisco TAC, or someone like me to come and take a look. If I’m honest, the simplest and best answer to the problem is “Remove the Tunnel from both ends and put it back again”. Just about every VPN tunnel I’ve put in that did not work, was a result of my fat fingers putting in the wrong subnet, IP address or shared secret.
However you can’t always remove the tunnel and start again, especially if you only have control of your end of the tunnel. In that case you need to do some troubleshooting and debugging.
Solution
To Troubleshoot and debug a VPN tunnel you need to have an appreciation of how VPN Tunnels work READ THIS.
Now you have read that you are an expert on IKE VPN Tunnels 🙂
Step 1
To bring up a VPN tunnel you need to generate some “Interesting Traffic” Start by attempting to send some traffic over the VPN tunnel.
User Access Verification
Password:
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********
PetesASA# show crypto isakmp
[/box]
You may see a lot more information if you have Existing VPN tunnels, but what you are looking for is this,
[box]
IKEv1 SAs:
Active SA: 2
Rekey SA: 0 (A tunnel will report 1 Active and 1 Rekey SA during rekey)
Total IKE SA: 2
1 IKE Peer: 123.123.123.123
Type : L2L Role : initiator
Rekey : no State : MM_ACTIVE <<YOUR SIDE BROUGHT THE VPN UP
There are no IKEv2 SAs
[/box]
If you see MM_ACTIVE (This means phase 1 has completed in Main Mode, and is active) So phase 1 has completed successfully, you need to jump forward and troubleshoot Phase 2.
Note: If you see AG_{something} this means you are trying to bring the tunnel up in aggressive mode!
If there is nothing listed at all – then your side is not even trying to bring up the tunnel. Try and generate a lot of VPN traffic – Like a persistent ping {ping 192.168.1.1 -t} and issue the show crypto isakmp command a few times to be sure. if you never see anything then its not getting as far as phase 1!
If your still reading this, then your problem is with Phase 1, and you have an ISAKMPSA state error.
ISAKMP SA MESSAGE STATES (On the Initiator)
MM_WAIT_MSG2
Message 1 has been sent to the responder but there has been no reply.
Causes:
1. There is no network connectivity to the firewallsecurity device at the other end, can you ping it?
2. The IP address of the far firewall is incorrect in the tunnel-group, issue a “show run tunnel-group” command, check you have a tunnel group with the correct IP address.
3. The IP address in the “Crypto Map” is incorrect, issue a “show run crypto map” command and check the line that ends “crypto map {name} {number} set peer xxx.xxx.xxx.xxx” to make sure.
4. You do not have a matching phase 1 policy with the other end, issue a “show run crypto isakmp” command make sure the other end has a matching policy, if you cant check the other end then generate some VPN traffic, issue the following command and check for the following,
[box]
EXAMPLE PHASE 1 POLICIES DONT MATCH
Password: Type help or ‘?’ for a list of available commands. PetesASA> en Password: ******** PetesASA#debug crypto isakmp 200
<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>
Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=ce4a3ffe) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 56 Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, Received an un-encrypted NO_PROPOSAL_CHOSEN notify message, dropping Apr 01 14:48:48 [IKEv1]: IP = 123.123.123.123, Information Exchange processing failed
<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>
[/box]
MM_WAIT_MSG4
The Phase 1 Policies have been agreed with both peers, the initiator is waiting for the responder to send it its keying information. I’ve seen two things cause this.
1. Different Vendors equipment talking the the ASA, or simply the version of OS on the ASA have been different.
2. There is a comms error, check there’s no router with firewall capabilities in the link.
MM_WAIT_MSG6
If there’s a firewall ‘in-between’ make sure UDP port 4500 is open for both peers.
Check your Pre-Shared Keys match on the ASA issue a “more system:running-config” then keep pressing the space bar till you see the tunnel- group and shared key
Again if you can’t check the other end then issue the following debug and the following will tell you if there is a key mismatch.
This error can also be seen if one end has PFS set and the other end does not. In this case the error will appear and dissapear and the connection is repeatedly “torn down”
e.g
crypto map outside_map 20 set pfs [box]
EXAMPLE PHASE 1 PRE SHARED KEYS DONT MATCH
Password: Type help or ‘?’ for a list of available commands. PetesASA> en Password: ******** PetesASA#debug crypto isakmp 200
<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>
Apr 01 15:11:47 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=5456d64e) with payloads : HDR + NOTIFY (11) + NONE (0) total length : 56 Apr 01 15:11:47 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, Received an un-encrypted PAYLOAD_MALFORMED notify message, dropping Apr 01 15:11:47 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, Error, peer has indicated that something is wrong with our message. This could indicate a pre-shared key mismatch. Apr 01 15:11:47 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, Information Exchange processing failed
<<<<<<<LOTS Of DEBUG TEXT REMOVED>>>>>>>
[/box]
ISAKMP SA MESSAGE STATES (On the Responder)
MM_WAIT_MSG3
The Phase 1 Policies have been agreed with both peers, the responder is waiting for the initiator to send it its keying information. I’ve seen two things cause this.
1. Different Vendors equipment talking the the ASA, or simply the version of OS on the ASA have been different.
2. There is a comms error, check there’s no router with firewall capabilities in the link.
3. I’ve seen this on a VPN from a VMware Edge Gateway, that had PFS (perfect forward secrecy) enabled, and the ASA did not.
If there’s a firewall ‘in-between’ make sure UDP port 4500 is open for both peers.
Here’s an Example of Phase one completing message by message successfully.
MESSAGE 1 (Leaving the Initiator)
[box]
Apr 01 11:38:51 [IKEv1]: IP = 123.123.123.123, IKE Initiator: New Phase 1, Intf inside, IKE Peer 123.123.123.123 local Proxy Address 192.168.1.0, remote Proxy Address 172.16.1.0, Crypto map (outside_map) Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing ISAKMP SA payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing NAT-Traversal VID ver 02 payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing NAT-Traversal VID ver 03 payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing NAT-Traversal VID ver RFC payload Apr 01 11:38:51 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing Fragmentation VID + extended capabilities payload Apr 01 11:38:51 [IKEv1]: IP = 123.123.123.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 168
[/box]
MESSAGE 2 (Arriving at the Responder)
[box]
Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + SA (1) + VENDOR (13) + NONE (0) total length : 117
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing SA payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Oakley proposal is acceptable
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing ke payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing nonce payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing Cisco Unity VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing xauth V6 VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Send IOS VID
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Constructing ASA spoofing IOS Vendor ID payload (version: 1.0.0, capabilities: 20000001)
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, constructing VID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, Send Altiga/Cisco VPN3000/Cisco ASA GW VID
[/box]
MESSAGE 3 (Leaving the Initiator)
[box]
Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + VENDOR (13) + VENDOR (13) + VENDOR (13) + VENDOR (13) + NONE (0) total length : 256
[/box]
MESSAGE 4 (Arriving at the Initiator)
[box]
Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + KE (4) + NONCE (10) + NONE (0) total length : 228
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing ke payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing ISA_KE payload
Apr 01 11:38:52 [IKEv1 DEBUG]: IP = 123.123.123.123, processing nonce payload
[/box]
MESSAGE 5 (Leaving the Initiator)
[box]
Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, Connection landed on tunnel_group 123.123.123.123
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Generating keys for Initiator...
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, constructing ID payload
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, constructing hash payload
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Computing hash for ISAKMP
Apr 01 11:38:52 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, constructing dpd vid payload
Apr 01 11:38:52 [IKEv1]: IP = 123.123.123.123, IKE_DECODE SENDING Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + VENDOR (13) + NONE (0) total length : 84
[/box]
MESSAGE 6 (Arriving at the Initiator)
[box]
Apr 01 11:38:53 [IKEv1]: IP = 123.123.123.123, IKE_DECODE RECEIVED Message (msgid=0) with payloads : HDR + ID (5) + HASH (8) + NONE (0) total length : 64
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, processing ID payload
Apr 01 11:38:53 [IKEv1 DECODE]: Group = 123.123.123.123, IP = 123.123.123.123, ID_IPV4_ADDR ID received 123.123.123.123
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, processing hash payload
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Computing hash for ISAKMP
Apr 01 11:38:53 [IKEv1]: IP = 123.123.123.123, Connection landed on tunnel_group 123.123.123.123
Apr 01 11:38:53 [IKEv1 DEBUG]: Group = 123.123.123.123, IP = 123.123.123.123, Oakley begin quick mode
Apr 01 11:38:53 [IKEv1 DECODE]: Group = 123.123.123.123, IP = 123.123.123.123, IKE Initiator starting QM: msg id = 26f952ae
Apr 01 11:38:53 [IKEv1]: Group = 123.123.123.123, IP = 123.123.123.123, PHASE 1 COMPLETED
[/box]
Note: You can debug Phase 1 traffic on a particular tunnel, with the following command.
debug crypto condition peer 123.123.123.123
or, simply;
debug crypto isakmp
Phase 1 Debug Errors
[box]
Petes-ASA((config)# debug crypto isakmp
Feb 29 11:49:08 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, QM FSM error (P2 struct &0x00007fda92308b10, mess id 0xc02b7a5d)!
Feb 29 11:49:08 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Removing peer from correlator table failed, no match!
Feb 29 11:49:08 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Session is being torn down. Reason: crypto map policy not found
[/box]
This was due to more than one misconfiguration, firstly the source and destination network objects in the interesting traffic ACL were the wrong way round! (Don’t forget to check your static NAT statement as well). And the TRANSFORM SET didn’t match, (sometimes you can see phase one established but then it disappears).
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
[box]
Petes-ASA((config)# debug crypto ikev1
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, No Group found by matching OU(s) from ID payload: Unknown
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, Trying to find group via IKE ID...
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, Trying to find group via IP ADDR...
Apr 19 16:36:10 [IKEv1]IP = 123.123.123.123, Connection landed on tunnel_group 123.123.123.123
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, peer ID type 2 received (FQDN)Apr 19 16:36:10 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Unable to compare IKE ID against peer cert Subject Alt Name
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, IKE MM Responder FSM error history (struct &0x00007ffd9e230670) <state>, <event>: MM_DONE, EV_ERROR-->MM_BLD_MSG6, EV_COMPARE_IDS-->MM_BLD_MSG6, EV_CERT_OK-->MM_BLD_MSG6, NullEvent-->MM_BLD_MSG6, EV_ACTIVATE_NEW_SA-->MM_BLD_MSG6, NullEvent-->MM_BLD_MSG6, EV_VALIDATE_CERT-->MM_BLD_MSG6, EV_UPDATE_CERT
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, IKE SA MM:3a1ed893 terminating: flags 0x01018002, refcnt 0, tuncnt 0
Apr 19 16:36:10 [IKEv1 DEBUG]Group = 123.123.123.123, IP = 123.123.123.123, sending delete/delete with reason message
[/box]
The ASA did not like the certificate presented by the remote peer, (Even though is was a good cert issued by NDES). To get past this you need to make a change to the tunnel group.
Petes-ASA((config)# debug crypto ikev1
%ASA-3-717009: Certificate validation failed. Peer certificate key usage is invalid, serial number: 6B00002B3F8571E2605FA02883000100002C3E, subject name: hostname=Petes-Router-Petes-HQ.petenetlive.com.
%ASA-3-717027: Certificate chain failed validation. Certificate chain is either invalid or not authorized.
[/box]
The ASA did not like the certificate presented by the remote peer, (Even though is was a good cert issued by NDES). To get past this you need to make a change to the trustpoint on the ASA.
[box]
Petes-ASA(config)# crypto ca trustpoint PNL-Trustpoint
Petes-ASA(config-ca-trustpoint)# ignore-ipsec-keyusage
[/box]
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
[box]
Petes-ASA# debug crypto ikev1
Petes-ASA# Feb 17 12:25:17 [IKEv1]Group = 123.123.123.123, IP = 123.123.123.123, Received encrypted Oakley Main Mode packet with invalid payloads, MessID = 0
Feb 17 12:25:17 [IKEv1]Group = 212.20.251.44, IP = 123.123.123.123, ERROR, had problems decrypting packet, probably due to mismatched pre-shared key. Aborting
Feb 17 12:25:23 [IKEv1]IP = 123.123.123.123, Header invalid, missing SA payload! (next payload = 4)
\
[/box]
Amazingly this had nothing to do with a mismatched pre shared key, the other end was set to use PFS (Perfect Forward Secrecy,) and my end (the ASA) was not.
If you have got this far the next step is to troubleshoot Phase 2
Related Articles, References, Credits, or External Links
Whilst messing around with my home firewall, I noticed that it no longer displayed the hostname on the command prompt,I checked Telnet and SSH, the results were the same.
Solution
Option 1 from Command Line
I’d managed to change the default setting for “prompt”
1. Log into the Firewall > go to “enable” mode then “Configure Terminal” mode.
[box]prompt ?[/box]
2. To change it back to the default, which is (hostname context) issue the following command.
[box]prompt hostname context[/box]
Note: You would only see the context if you were in multiple mode! You can also add the following,
hostname – the firewalls name. domain – The firewall configured domain name. priority – Only when deployed in fail over mode. (pri – primary and sec – secondary). state – Only when deployed in fail over mode. (act – active, stby – standby, actNoFailover – fail over not enabled and unit is active, and stbyNoFailover – fail over not enabled and unit is in standby).
Option 2 from ASDM
1. Open the ASDM and Navigate to Configuration > Device Management > Management Access > CLI Prompt > Add and Delete as applicable. (Screen shot shows the default).
Click for larger image.
2. When done, click File > Save running configuration to flash.
Related Articles, References, Credits, or External Links
1. I like to name the DMZ entities IP addresses so things look neat.
[box]
PetesASA(config)# name 172.16.1.1 DMZ-Host-Private-IP
PetesASA(config)# name 123.123.123.124 DMZ-Host-Public-IP2. Set a some NAT statement to handle traffic flow. (assuming you have a matching global statement like global (outside) 1 xxx - "show run global" will tell you).
[/box] [box]
PetesASA(config)# nat (DMZ) 1 0.0.0.0 0.0.0.0
[/box]
Note We are only going to have one DMZ host, and it will have a static mapping – if you had many DMZ hosts then also add “global (DMZ) 1 interface”.
Once again there’s a slight change in the syntax based on the ASA version, after version 8.3 you allow access to the ‘Pre-Natted’ address, but before version 8.3 you allowed access to the ‘Post-Natted’ address.
ASA Version 8.3 and Newer Access Lists
1. To let people from outside you need to either create an access-list or add some rules to any existing inbound access-list. (“show run access-group” will tell you, look for an ACL applies “in” to the outside interface e.g. “access-group outbound in interface inside”. We will assume I don’t have one so I’ll need the access-group at the end..
[box]
PetesASA(config)# access-list inbound extended permit tcp any object DMZ-Host-INT eq www
PetesASA(config)# access-list inbound extended permit tcp any object DMZ-Host-INT eq https
PetesASA(config)# access-group inbound in interface outside
[/box]
2. Now to allow the DMZ host to get to the database server I’m going to allow TCP 1433.
1. To let people in from the outside you need to either create an access-list or add some rules to any existing inbound access-list. (“show run access-group” will tell you, look for an ACL applies “in” to the outside interface e.g. “access-group outbound in interface inside”. We will assume I don’t have one so I’ll need the access-group at the end.
[box]PetesASA(config)# access-list inbound extended permit tcp any host DMZ-Host-Public-IP eq www PetesASA(config)# access-list inbound extended permit tcp any host DMZ-Host-Public-IP eq https PetesASA(config)# access-group inbound in interface outside 2. Now to allow the DMZ host to get to the database server I’m going to allow TCP 1433.
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.