Cisco ASA Disable ESMTP Inspection

Telnet to Exchange on Port 25 shows a row of Asterisks?

KB ID 0000536

Problem

Yesterday my colleague Ben called me over to the help-desk and asked “Have you ever seen this before?” This was what was on his screen.

220 ***************************************************

Solution

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 TLS DO NOT do this. (see here).

1. Connect to the the Cisco ASA, either by serial cable, Telnet or SSH.

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.

Disable ESMTP Inspection on Cisco ASA via ASDM

1. Connect to the the Cisco ASA, via ASDM.

2. Navigate to Configuration > Firewall > Service Policy Rules > Global Policy > Inspection_Default > Rule Actions > untick ESMTP > OK > Apply > File > Save Running Configuration to flash.

Enable the Banner and Keep ESMTP Inspection on

You need to create a policy map that will not mask the banner and add that to the default inspection map, like so;

[box]

PetesASA> en
Password:*********
PetesASA#configure terminal
PetesASA(config)#policy-map type inspect esmtp tls-allow 
PetesASA(config-pmap-p)#parameters
PetesASA(config-pmap-p)#allow-tls
PetesASA(config-pmap-p)#no mask-banner
PetesASA(config-pmap-p)#exit
PetesASA(config)#policy-map global_policy 
PetesASA(config-pmap)#class inspection_default 
PetesASA(config-pmap-c)#no inspect esmtp
PetesASA(config-pmap-c)#inspect esmtp tls-allow 
PetesASA(config-pmap-c)#exit
PetesASA(config)# write mem
Building configuration...
Cryptochecksum: b984ffbc dd77cdbf f2cd8d86 0b8f3f96
3965 bytes copied in 1.490 secs (3965 bytes/sec)
[OK]

[/box]

 

 

Related Articles, References, Credits, or External Links

NA

Juniper SRX Firewall – Allow ‘Ping’

KB ID 0000706 

Problem

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

Original Article Written 07/11/12

 

Juniper SRX Firewall – Allow Web Management from Outside

KB ID 0000708 

Problem

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

NA

 

Troubleshooting Phase 1 Cisco Site to Site (L2L) VPN Tunnels

KB ID 0000216

Problem

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.

Step 2 See if Phase 1 has completed.

Connect to the firewall and issue the following commands.

[box]

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 ISAKMP SA 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

e.g.

tunnel-group 123.123.123.123 ipsec-attributes pre-shared-key this-is-the-pre-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.

Also see: Cisco ASA VPN to Cisco Router “MM_WAIT_MSG3”

MM_WAIT_MSG5

Make sure the Pre-Shared Keys Match

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.

[box]

Petes-ASA(config)# tunnel-group TG-TUNNEL-HQ ipsec-attributes
Petes-ASA(config-ipsec)# peer-id-validate nocheck

[/box]

Or if you prefer the ASDM;

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

[box]

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

Troubleshooting Phase 2 Cisco Site to Site (L2L) VPN Tunnels

Thanks To SteveH for the Certificate Phase 1 Error details.

Cisco Firewalls ‘My Prompt has changed / Disappeared’

KB ID 0000226

Problem

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

NA

ASA 5500 Adding a DMZ Step By Step

KB ID 0000316 

Problem

Assuming you have a working ASA 5500 and you want to add a DMZ to it, this is the process.

Assumptions

1. Networks,

a. Inside network is 10.1.0.0 255.255.0.0 b. Outside network is 123.123.123.120 255.255.255.248 c. DMZ network is 172.16.1.0 255.255.0.0

2. Interfaces,

a. Inside Interface is 10.1.0.254 b. Outside Interface is 172.16.1.254 c. DMZ Interface is 172.16.1.254

3. The Web server in the DMZ will have the following IP addresses,

a. DMZ IP address 172.16.1.1 b. Public IP address 123.123.123.124

4. From the Internet you want to allow web traffic and secure web traffic (http/www and https/ssl) to the DMZ Server.

5. The DMZ Server needs to speak to a database server on the inside LAN, on TCP port 1433.

 

Solution

Step 1: Setup the DMZ Interface

1. Firstly connect to the ASA log in and go to enable mode.

[box]

User Access Verification

Password:
Type help or '?' for a list of available commands.
PetesASA> enable
Password: ********

[/box]

2. Go to configure terminal mode and set up the DMZ interface (In this case Ethernet0/2).

[box]

PetesASA# configure terminal
PetesASA(config)# interface Ethernet0/2
PetesASA(config-if)# nameif DMZ
PetesASA(config-if)# security-level 50
PetesASA(config-if)# ip address 172.16.1.254 255.255.0.0
PetesASA(config-if)# no shutdown
PetesASA(config-if)# exit

[/box]

Step 2: Setup the DMZ NAT

Before we worry about the NAT, we need to find out what version of code the ASA is running, (configuration of NAT changes in version 8.3).

Find out your Cisco ASA version (Operating system and ASDM)

ASA Version 8.3 and Newer DMZ NAT

1. Allow the IP addresses in the DMZ to be NATTED to the outside IP address, (we will set up a static translation for the DMZ host in a minute).

[box]

PetesASA(config)# object network DMZ-subnet
PetesASA(config-network-object)# subnet 172.16.1.0 255.255.0.0
PetesASA(config-network-object)# nat (DMZ,outside) dynamic interface
PetesASA(config-network-object)# exit
PetesASA(config)#

[/box]

2. Specify the public IP of the DMZ host.

[box]

PetesASA(config)# object network DMZ-Host-EXT
PetesASA(config-network-object)# host 123.123.123.124
PetesASA(config-network-object)# exit
PetesASA(config)#

[/box]

3. Create a static NAT translation for the public ip of the DMZ host, to its private IP.

[box]

PetesASA(config)# object network DMZ-Host-INT
PetesASA(config-network-object)# host 172.16.1.1
PetesASA(config-network-object)# nat (DMZ,outside) static DMZ-Host-EXT
PetesASA(config-network-object)# exit
PetesASA(config)#

[/box]

ASA Version 8.2 and Older DMZ NAT

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”.

3. Now add some static mappings.

[box]

PetesASA(config)# static (DMZ,outside) DMZ-Host-Public-IP DMZ-Host-Private-IP netmask 255.255.255.255
PetesASA(config)# static (inside,DMZ) 10.1.0.0 10.1.0.0 netmask 255.255.0.0
PetesASA(config)# static (inside,DMZ) 172.16.1.0 172.16.1.0 netmask 255.255.255.0

[/box]

Step 4: Create ACL’s to Allow Traffic

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.

[box]PetesASA(config)# access-list DMZ-outbound permit tcp object DMZ-Host-INT host 10.1.0.100 eq 1433 PetesASA(config)# access-group DMZ-outbound in interface DMZ[/box]

ASA Version 8.2 and Older Access Lists

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.

PetesASA(config)# access-list DMZ_outbound extended permit tcp host DMZ-Host-Private-IP host DMS-SQL eq 1433 PetesASA(config)# access-group DMZ_outbound in interface DMZ[/box]

Step 5: Save the changes

8. Finally save the configuration.

[box]

PetesASA(config)#
write mem
Building configuration...
Cryptochecksum: 5417d5a1 bee8b082 16c6f19d b3839f139379 bytes copied in 1.410 secs (9379 bytes/sec)
[OK]

[/box]

Related Articles, References, Credits, or External Links

Original Article Written 27/08/10

Cisco ASA to Juniper SRX Site to Site VPN

KB ID 0000710

Problem

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.

Step 1 – Configure the ASA

Model used Cisco ASA 5505 v8.4 (ASDM 6.4)

1. Connect to the ASDM > Wizards > VPN Wizards > Site-to-site VPN Wizard.

2. Next.

3. Enter the public IP address of the Juniper Firewall > Next, (Note: I’m assuming the VPN is terminated on the outside interface, if not change it).

4. IKE version 1 > Next.

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).

7. Accept the default of 3DES and SHA1 > Next.

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

  1. 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.
  2. Policy based VPN – VPN is selected based on the policy.

12. Log onto the Juniper Web Device Manager.

13. Tasks > Configure VPN > Launch VPN Wizard.

14. Accept the default of Site-to-site > Start.

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.

18. Accept the defaults > Next.

19. Review the settings > Commit.

Step 3 – Additional Steps required (for Cisco ASA)

20. Navigate to IPsec VPN > Auto Tunnel > Phase II > Select your tunnel > Edit > IPsec VPN 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.

Juniper KB Articles

 

SRX Getting Started – Configure VPN tunnel for site-to-site connectivity

How to configure IPSec VPN on a J Series or SRX Series device