Understanding IP Source Guard

Tags

, , , , , , , , , ,

800px-Cisco_logo.svg

IP source guard is a security feature that restricts IP traffic on non-routed, Layer 2 interfaces by filtering traffic based on the DHCP snooping binding database and on manually configured IP source bindings. You can use IP source guard to prevent traffic attacks caused when a host tries to use the IP address of its neighbor.

You can enable IP source guard when DHCP snooping is enabled on an untrusted interface. After IP source guard is enabled on an interface, the switch blocks all IP traffic received on the interface, except for DHCP packets allowed by DHCP snooping. A port access control list (ACL) is applied to the interface. The port ACL allows only IP traffic with a source IP address in the IP source binding table and denies all other traffic.

The IP source binding table has bindings that are learned by DHCP snooping or are manually configured (static IP source bindings). An entry in this table has an IP address, its associated MAC address, and its associated VLAN number. The switch uses the IP source binding table only when IP source guard is enabled.

IP source guard is supported only on Layer 2 ports, including access and trunk ports.You can configure IP source guard with source IP address filtering or with source IP and MAC address filtering.

These sections contain this information:

•Source IP Address Filtering
•Source IP and MAC Address Filtering

Source IP Address Filtering

When IP source guard is enabled with this option, IP traffic is filtered based on the source IP address. The switch forwards IP traffic when the source IP address matches an entry in the DHCP snooping binding database or a binding in the IP source binding table.

When a DHCP snooping binding or static IP source binding is added, changed, or deleted on an interface, the switch modifies the port ACL using the IP source binding changes, and re-applies the port ACL to the interface.

If you enable IP source guard on an interface on which IP source bindings (dynamically learned by DHCP snooping or manually configured) are not configured, the switch creates and applies a port ACL that denies all IP traffic on the interface. If you disable IP source guard, the switch removes the port ACL from the interface.

Source IP and MAC Address Filtering

When IP source guard is enabled with this option, IP traffic is filtered based on the source IP and MAC addresses. The switch forwards traffic only when the source IP and MAC addresses match an entry in the IP source binding table.

When IP source guard with source IP and MAC address filtering is enabled, the switch filters IP and non-IP traffic. If the source MAC address of an IP or non-IP packet matches a valid IP source binding, the switch forwards the packet. The switch drops all other types of packets except DHCP packets.

The switch uses port security to filter source MAC addresses. The interface can shut down when a port-security violation occurs.

Default IP Source Guard Configuration

By default, IP source guard is disabled.

IP Source Guard Configuration Guidelines

These are the configuration guides for IP source guard:

•You can configure static IP bindings only on nonrouted ports. If you enter the ip source binding mac-address vlan vlan-id ip-address interface interface-id global configuration command on a routed interface, this error message appears:

•Static IP source binding can only be configured on switch port.

•When IP source guard with source IP filtering is enabled on a VLAN, DHCP snooping must be enabled on the access VLAN to which the interface belongs.

•If you are enabling IP source guard on a trunk interface with multiple VLANs and DHCP snooping is enabled on all the VLANs, the source IP address filter is applied on all the VLANs

•When IP source guard with source IP and MAC address filtering is enabled, DHCP snooping and port security must be enabled on the interface.

•When configuring IP source guard on interfaces on which a private VLAN is configured, port security is not supported.

•IP source guard is not supported on EtherChannels.

•You can enable this feature when IEEE 802.1x port-based authentication is enabled.

•If the number of ternary content addressable memory (TCAM) entries exceeds the maximum available, the CPU usage increases.

This example shows how to enable IP source guard with source IP and MAC filtering.

Switch# configure terminal
Enter configuration commands, one per line. End with CNTL/Z.
Switch(config)# interface gigabitethernet1/0/1
Switch(config-if)# ip verify source port-security
Switch(config-if)# exit
Switch(config)# ip source binding 0100.0022.0010 vlan 10 10.0.0.2 interface 
gigabitethernet1/0/1
Switch(config)# ip source binding 0100.0230.0002 vlan 11 10.0.0.4 interface 
gigabitethernet1/0/1
Switch(config)# end

Commands for Displaying IP Source Guard Information

show ip source binding --> Display the IP source bindings on a switch
show ip verify source --> Display the IP source guard configuration on the switch

 

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

 

Advertisements

ASA – Anyconnect ‘IKEv2’ configuration

Tags

, , , , , ,

Secure VPN remote access historically has been limited to IPsec (IKEv1) and SSL. These were supported using the “Cisco VPN client” for IPsec based VPN and Anyconnect for SSL based VPN.  Each of those products only supported their own protocol however with the introduction of Anyconnect Secure Mobility Client 3.0, the client can now use IPsec (IKEv2) or SSL for the transport of the VPN connection.

The remainder of this document will discuss the steps to configure an ASA to support Anyconnect clients using IKEv2.

Requirements:

1)     ASA running version 8.4.1 or later
2)     Anyconnect Secure Mobility Client 3.0 or later
3)     License for Anyconnect Peer (either “AnyConnect Essentials” or “AnyConnect Permium Peers”)

It is possible to configure the setup either through ASDM or via the CLI.  Using the former is the easiest and is listed below along with the CLI commands that are generated.

Configure via ASDM:

1)     Start ASDM
2)     Wizards -> VPN Wizards -> AnyConnect Wizard
3)     Configure a name for the tunnel group – RemoteAccessIKEv2

1

4) Configure the connection protocols.  It is possible to have both SSL and IPsec connections on the same tunnel group however in this example only IPsec will be selected.

2

5) Upload Anyconnect images to the ASA for each platform that need supporting (Windows, Mac, Linux).

3

6) Configure the user database.  If using the Local database users can be added/removed here.  If using a remote authentication server configure a new “AAA Server Group” by clicking on the “New…” button.

4

7) Create a pool of addresses that will get assigned to the vpn clients.

5

8)  Define the default domain name for the virtual adapter on the client and the internal DNS servers

6

9) Allow the VPN traffic to be exempted from NAT when accessing the internal network.

7

10)  Turn off Web Launch.  This is optional and would require the client to be pre-deployed (much in the same fashion as the Cisco VPN client).

If you wish to keep Web Launch on then SSL must also be checked on step 3.

8

11)  Save and Apply the configuration

At this point the ASA will have these commands added:

Commands Function
crypto ikev2 policy 1encryption aes-256integrity shagroup 5 2 1prf shalifetime seconds 86400

crypto ikev2 policy 10

encryption aes-192

integrity sha

group 2

prf sha

lifetime seconds 86400

crypto ikev2 policy 20

encryption aes

integrity sha

group 2

prf sha

lifetime seconds 86400

crypto ikev2 policy 30

encryption 3des

integrity sha

group 2

prf sha

lifetime seconds 86400

crypto ikev2 policy 40

encryption des

integrity sha

group 2

prf sha

lifetime seconds 86400

crypto ikev2 enable outside client-services port 443

crypto ikev2 remote-access trustpoint rtpvpnoutbound7

This is adding the IKEv2 Policies.It also specifiies the certificate the ASA uses for IKEv2.
crypto ikev2 enable outside client-services port 443ssl trust-point rtpvpnoutbound7 outside Enabling client-services on the outside interface.It also specifies the certificate the ASA uses for SSL.client-services run over SSL.
crypto ipsec ikev2 ipsec-proposal DESprotocol esp encryption desprotocol esp integrity sha-1 md5crypto ipsec ikev2 ipsec-proposal 3DESprotocol esp encryption 3desprotocol esp integrity sha-1 md5

crypto ipsec ikev2 ipsec-proposal AES

protocol esp encryption aes

protocol esp integrity sha-1 md5

crypto ipsec ikev2 ipsec-proposal AES192

protocol esp encryption aes-192

protocol esp integrity sha-1 md5

crypto ipsec ikev2 ipsec-proposal AES256

protocol esp encryption aes-256

protocol esp integrity sha-1 md5

These define the transform sets that IKEv2 can use.
crypto map out-map 65000 ipsec-isakmp dynamic out-dyn-mapcrypto map out-map interface outsidecrypto dynamic-map out-dyn-map 10 set ikev2 ipsec-proposal AES256 AES192 AES 3DES DES This configures the crypto map to use the IKEv2 transform-sets
webvpnanyconnect image disk0:/anyconnect-linux-3.1.0059-k9.pkg 1anyconnect image disk0:/anyconnect-macosx-i386-3.0.4235-k9.pkg 2anyconnect image disk0:/anyconnect-win-3.0.1047-k9.pkg 5anyconnect profiles RemoteAccessIKEv2_client_profile disk0:/RemoteAccessIKEv2_client_profile.xmlanyconnect enable This configures the ASA to allow Anyconnect connections and the valid Anyconnect images.  If Web Launch is allowed it will installthe clients on the computers on first connect.In addition there is the programming of the profile that will be used by the client.
group-policy GroupPolicy_RemoteAccessIKEv2 internalgroup-policy GroupPolicy_RemoteAccessIKEv2 attributesvpn-tunnel-protocol ikev2dns-server value 10.1.2.3wins-server nonedefault-domain value example.com

webvpn

anyconnect profiles value RemoteAccessIKEv2_client_profile type user

This configures the group-policy to allow IKEv2 connections and defines which Anyconnect profile for the user.
ip local pool vpnpool 10.7.7.135-10.7.7.140 mask 255.255.255.0 This defines a pool of addresses.
tunnel-group RemoteAccessIKEv2 type remote-accesstunnel-group RemoteAccessIKEv2 general-attributesdefault-group-policy GroupPolicy_RemoteAccessIKEv2address-pool  vpnpooltunnel-group RemoteAccessIKEv2 webvpn-attributesgroup-alias RemoteAccessIKEv2 enable This ties the pool of addressess to the vpn connection.
object network NETWORK_OBJ_10.7.7.128_28subnet 10.7.7.128 255.255.255.240 Defines an object (will be used later)
nat (inside,outside) 8 source static any any destination static NETWORK_OBJ_10.7.7.128_28 NETWORK_OBJ_10.7.7.128_28 Defines the NAT rule that exempts the vpn traffic from being NATted.
<?xml version=”1.0″ encoding=”UTF-8″?><AnyConnectProfile xmlns=”http://schemas.xmlsoap.org/encoding/“><ServerList><HostEntry><HostName>rtpvpnoutbound7 (IPsec)</HostName><HostAddress>64.102.156.88</HostAddress>

<PrimaryProtocol>IPsec</PrimaryProtocol>

</HostEntry>

</ServerList>

</AnyConnectProfile>

This is the contents of the profile that gets written the ASA flash as RemoteAccessIKEv2_client_profile.xml

Testing:

If Web Launch was configured, on the client open up a web-browser and log into the ASA.  The client will self download and install.  It will connect with TLS/DTLS first.  If you disconnect, quit the client, then restart the client there will be a drop down entry for the IKEv2 connection.  Select it and the client will initate using IKEv2.

If Web Launch was not configured it will be necessary to manually install the client on the computer and to copy the

RemoteAccessIKEv2_client_profile.xml into the profile directory.  Start the client and select the drop down.  The connection will be initiated using IKEv2.

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

Packet Capture on High-End SRX devices

Tags

, , , , , ,

To obtain packet capture on High-End SRX devices, perform the following procedure:

  • Configure the datapath-debug on the device under the hierarchy:
  • [edit security datapath-debug].

       To configure the device for data path debugging:

  • Specify the following request command to set the data path debugging for the multiple processing units along the packet-processing path:
[edit]user@host# set security datapath-debug
  • Specify the trace options for data path-debug using the following command:
[edit]user@host# set security datapath-debug traceoptions
  • Using the request security packet-filter command, you can set the packet filter to specify the related packets to perform data path-debug action. A maximum of four filters are supported at the same time. For example, the following command sets the first packet-filter:
[edit]user@host# set security datapath-debug packet-filter name
  • Using the request security action-profile command, you can set the action for the packet match for a specified filter. Only the default action profile is supported, which is the trace option for network processor ezchip ingress, ezchip egress, spu.lbt, and spu.pot:
[edit]user@host# set security datapath-debug packet-filter name action-profile
  • Based on the exact requirements, you may need to trace only a certain type of traffic which can be configured used packet-filters.
  • Specify maximum capture size (this is the maximum size captured per packet).
  • Create an action-profile to specify where, inside the device, the packets will be captured (eg : LBT, MAC-ingress, and so on).
  • Refer the previously created action-profile inside the configured packet-filter.
  • Specify the name of the capture-file (the file which will contain the captured packets).

Sample Configuration:

root> show configuration security datapath-debug | no-more 
 traceoptions {
      file debugtrace;
 }
 capture-file datapcap format pcap;
 maximum-capture-size 1500;
 action-profile {
      flowtrace {
          event pot {
              packet-dump;
          }
          event lbt {
              packet-dump;
          }
      }
 }
 packet-filter filter1 {
      action-profile flowtrace;
      protocol icmp;
 }
  • In the above config, only the most relevant portions required for the solution are provided.
  • Packets will be dumped in the capture-file, only during processing in POT and LBT threads as per the above config.

Procedure for obtaining the captured packets:

After the config has been placed, remember to start the datapath-debug in the device. It does not start by itself.

To start the debug :

[edit]
 root> request security datapath-debug capture start

To stop the debug :

[edit]
 root> request security datapath-debug capture stop
  • Remember to stop the debug, after you are done with the capturing of data. If you attempt to open the capture files without stopping the debug, the files obtained cannot be opened through any third party software.
  • After the captures have been done, you will be able to view the packets on the CLI in HEX format using the command :
[edit] root> show security datapath-debug capture

you would like to view the captured files in any third party software (eg. Tcpdump, Wireshark), then you will need to remove certain fields in each of the packets. The command is:

root@% e2einfo -Ccapture -Snormalize -I datapcap -F datapcap.pcap

The files containing the captured data is under ‘/var/log’. You should be able to view the files (capture-file and the packet-capture file created) under the /var/log directory.

root> start shell 
 root@% cd /var/log
 root@% ls -l 
 total 18964
 -rw-r--r-- 1 root wheel 80560 Apr 6 06:42 KR2
 -rw-r----- 1 root wheel 774142 Apr 19 03:51 RPF-CHECK
 -rw-r----- 1 root wheel 445638 Jun 21 11:48 RPF-CHECK-ON
 -rw-r----- 1 root wheel 86453 Jun 2 20:31 RPF-CHECK-ON.0.gz
 -rw-r--r-- 1 root wheel 275 Jul 20 19:38 __jsrpd_commit_check__
 -rw-r--r-- 1 root wheel 0 Dec 21 2010 authd_sdb.log
 -rw-r--r-- 1 root wheel 0 Jul 27 21:43 capture.pcap
 -rw-r----- 1 root wheel 1975225 Aug 3 21:31 chassisd
 -rw-r----- 1 root wheel 203000 Jul 1 08:52 chassisd.0.gz
 -rw-r----- 1 root wheel 195019 Jun 3 10:20 chassisd.1.gz
 -rw-r----- 1 root wheel 191531 Jun 3 09:49 chassisd.2.gz
 -rw-r----- 1 root wheel 194656 Jun 3 08:54 chassisd.3.gz
 -rw-r--r-- 1 root wheel 20835 Aug 3 21:23 cosd
 -rw-r----- 1 root wheel 12672 Aug 3 21:34 datapcap
 -rw-r--r-- 1 root wheel 10440 Aug 3 21:36 datapcap.pcap
 -rw-r----- 1 root wheel 979500 Aug 3 21:26 dcd
 -rw-r----- 1 root wheel 28712 Jun 3 06:44 dcd.0.gz
 -rw-r----- 1 root wheel 27720 Jun 3 00:52 dcd.1.gz
 -rw-r----- 1 root wheel 41132 Aug 3 21:26 debugtrace

 

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

Understanding Denial-of-Service Attacks

Tags

, , , , ,

What is a denial-of-service (DoS) attack?

In a denial-of-service (DoS) attack, an attacker attempts to prevent legitimate users from accessing information or services. By targeting your computer and its network connection, or the computers and network of the sites you are trying to use, an attacker may be able to prevent you from accessing email, websites, online accounts (banking, etc.), or other services that rely on the affected computer.

The most common and obvious type of DoS attack occurs when an attacker “floods” a network with information. When you type a URL for a particular website into your browser, you are sending a request to that site’s computer server to view the page. The server can only process a certain number of requests at once, so if an attacker overloads the server with requests, it can’t process your request. This is a “denial of service” because you can’t access that site.

An attacker can use spam email messages to launch a similar attack on your email account. Whether you have an email account supplied by your employer or one available through a free service such as Yahoo or Hotmail, you are assigned a specific quota, which limits the amount of data you can have in your account at any given time. By sending many, or large, email messages to the account, an attacker can consume your quota, preventing you from receiving legitimate messages.

ddos-attack

What is a distributed denial-of-service (DDoS) attack?

In a distributed denial-of-service (DDoS) attack, an attacker may use your computer to attack another computer. By taking advantage of security vulnerabilities or weaknesses, an attacker could take control of your computer. He or she could then force your computer to send huge amounts of data to a website or send spam to particular email addresses. The attack is “distributed” because the attacker is using multiple computers, including yours, to launch the denial-of-service attack.

How do you avoid being part of the problem?

Unfortunately, there are no effective ways to prevent being the victim of a DoS or DDoS attack, but there are steps you can take to reduce the likelihood that an attacker will use your computer to attack other computers:

  • Install and maintain anti-virus software
  • Install a firewall, and configure it to restrict traffic coming into and leaving your computer
  • Follow good security practices for distributing your email address. Applying email filters may help you manage unwanted traffic.

How do you know if an attack is happening?

Not all disruptions to service are the result of a denial-of-service attack. There may be technical problems with a particular network, or system administrators may be performing maintenance. However, the following symptoms could indicate a DoS or DDoS attack:

  • unusually slow network performance (opening files or accessing websites)
  • unavailability of a particular website
  • inability to access any website
  • dramatic increase in the amount of spam you receive in your account

What do you do if you think you are experiencing an attack?

Even if you do correctly identify a DoS or DDoS attack, it is unlikely that you will be able to determine the actual target or source of the attack. Contact the appropriate technical professionals for assistance.

  • If you notice that you cannot access your own files or reach any external websites from your work computer, contact your network administrators. This may indicate that your computer or your organization’s network is being attacked.
  • If you are having a similar experience on your home computer, consider contacting your internet service provider (ISP). If there is a problem, the ISP might be able to advise you of an appropriate course of action.

 You may have heard of denial-of-service attacks launched against websites, but you can also be a victim of these attacks. Be up to date and have a pleasant computing.

 

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

Route Based l2l VPN configuration in SRX [ Junos ]

Tags

, , , , ,

With route-based VPNs, a policy does not specifically reference a VPN tunnel. Instead, the policy references a destination address. When the security device does a route lookup to find the interface through which it must send traffic to reach that address, it finds a route via a secure tunnel (ST) interface, which is bound to a specific VPN tunnel.

The following are reasons why you implement route-based VPN:

  • Source or destination NAT (NAT-src or NAT-dst) needs to occur as traffic travels through the VPN.
  • There are overlapping subnets or IP addresses between the two LANs.
  • Hub-and-spoke VPN topology is used in the network.
  • Primary and backup VPN are required.
  • A dynamic routing protocol (for example, OSPF, RIP, or BGP) is running across the VPN.
  • Multiple subnets or networks at the remote site across the VPN need to be accessed.

R-VPN-Secureleaves

Procedure

  1. Configure Ethernet interface information.
    [edit]
    user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.10.10.1/24
    user@host# set interfaces ge-0/0/3 unit 0 family inet address 1.1.1.2/30
    user@host# set interfaces st0 unit 0 family inet address 10.11.11.10/24
  2. Configure static route information.
    [edit]
    user@host# set routing-options static route 0.0.0.0/0 next-hop 1.1.1.1
    user@host# set routing-options static route 192.168.168.0/24 next-hop st0.0
  3. Configure the untrust security zone.
    [edit ]user@host# edit security zones security-zone untrust
  4. Assign an interface to the security zone.
    [edit security zones security-zone untrust]
    user@host# set interfaces ge-0/0/3.0
  5. Specify allowed system services for the security zone.
    [edit security zones security-zone untrust]
    user@host# set host-inbound-traffic system-services ike
  6. Configure the trust security zone.
    [edit]
    user@host# edit security zones security-zone trust
  7. Assign an interface to the trust security zone.
    [edit security zones security-zone trust]
    user@host# set interfaces ge-0/0/0.0
  8. Specify allowed system services for the trust security zone.
    [edit security zones security-zone trust]
    user@host# set host-inbound-traffic system-services all
  9. Configure an address book and attach a zone to it.
    [edit security address-book book1]
    user@host# set address sunnyvale 10.10.10.0/24
    user@host# set attach zone trust
  10. Configure the vpn-chicago security zone.
    [edit]user@host# edit security zones security-zone vpn-chicago
  11. Assign an interface to the security zone.
    [edit security zones security-zone vpn-chicago]
    user@host# set interfaces st0.0
  12. Configure another address book and attach a zone to it.
    [edit security address-book book2]
    user@host# set address chicago 192.168.168.0/24
    user@host# set attach zone vpn-chicago

    To configure IKE:

    1. Create the IKE Phase 1 proposal.
      [edit security ike]
      user@host# set proposal ike-phase1-proposal
    2. Define the IKE proposal authentication method.
      [edit security ike proposal ike-phase1-proposal]
      user@host# set authentication-method pre-shared-keys
    3. Define the IKE proposal Diffie-Hellman group.
      [edit security ike proposal ike-phase1-proposal]
      user@host# set dh-group group2
    4. Define the IKE proposal authentication algorithm.
      [edit security ike proposal ike-phase1-proposal]
      user@host# set authentication-algorithm sha1
    5. Define the IKE proposal encryption algorithm.
      [edit security ike proposal ike-phase1-proposal]
      user@host# set encryption-algorithm aes-128-cbc
    6. Create an IKE Phase 1 policy.
      [edit security ike]user@host# set policy ike-phase1-policy
    7. Set the IKE Phase 1 policy mode.
      [edit security ike policy ike-phase1-policy]
      user@host# set mode main
    8. Specify a reference to the IKE proposal.
      [edit security ike policy ike-phase1-policy]
      user@host# set proposals ike-phase1-proposal
    9. Define the IKE Phase 1 policy authentication method.
      [edit security ike policy ike-phase1-policy]
      user@host# set pre-shared-key ascii-text 395psksecr3t
    10. Create an IKE Phase 1 gateway and define its external interface.
      [edit security ike]
      user@host# set gateway gw-chicago external-interface ge-0/0/3.0
    11. Define the IKE Phase 1 policy reference.
      [edit security ike gateway gw-chicago]
      user@host# set ike-policy ike-phase1-policy
    12. Define the IKE Phase 1 gateway address.
      [edit security ike gateway gw-chicago]
      user@host# set address 2.2.2.2

    If you are done configuring the device, enter commit from configuration mode.

    Configuring IPsec

    To configure IPsec:

    1. Create an IPsec Phase 2 proposal.
      [edit]
      user@host# set security ipsec proposal ipsec-phase2-proposal
    2. Specify the IPsec Phase 2 proposal protocol.
      [edit security ipsec proposal ipsec-phase2-proposal]
      user@host# set protocol esp
    3. Specify the IPsec Phase 2 proposal authentication algorithm.
      [edit security ipsec proposal ipsec-phase2-proposal]
      user@host# set authentication-algorithm hmac-sha1-96
    4. Specify the IPsec Phase 2 proposal encryption algorithm.
      [edit security ipsec proposal ipsec-phase2-proposal]
      user@host# set encryption-algorithm aes-128-cbc
    5. Create the IPsec Phase 2 policy.
      [edit security ipsec]
      user@host# set policy ipsec-phase2-policy
    6. Specify the IPsec Phase 2 proposal reference.
      [edit security ipsec policy ipsec-phase2-policy]
      user@host# set proposals ipsec-phase2-proposal
    7. Specify IPsec Phase 2 PFS to use Diffie-Hellman group 2.
      [edit security ipsec policy ipsec-phase2-policy]
      user@host# set perfect-forward-secrecy keys group2
    8. Specify the IKE gateway.
      [edit security ipsec]
      user@host# set vpn ike-vpn-chicago ike gateway gw-chicago
    9. Specify the IPsec Phase 2 policy.
      [edit security ipsec]
      user@host# set vpn ike-vpn-chicago ike ipsec-policy ipsec-phase2-policy
    10. Specify the interface to bind.
      [edit security ipsec]
      user@host# set vpn ike-vpn-chicago bind-interface st0.0

    Configuring Security Policies

    To configure security policies:

    1. Create the security policy to permit traffic from the trust zone to the vpn-chicago zone.
      [edit security policies from-zone trust to-zone vpn-chicago]
      user@host# set policy vpn-tr-chi match source-address sunnyvale
      user@host# set policy vpn-tr-chi match destination-address chicago
      user@host# set policy vpn-tr-chi match application any
      user@host# set policy vpn-tr-chi then permit
    2. Create the security policy to permit traffic from the vpn-chicago zone to the trust zone.
      [edit security policies from-zone vpn-chicago to-zone trust]
      user@host# set policy vpn-chi-tr match source-address sunnyvale
      user@host# set policy vpn-chi-tr match destination-address chicago
      user@host# set policy vpn-chi-tr match application any
      user@host# set policy vpn-chi-tr then permit

    Configuring TCP-MSS

    1. Configure TCP-MSS information.
      [edit]
      user@host# set security flow tcp-mss ipsec-vpn mss 1350

    Verify all the parameters which configured now.

    Before starting the verification process, you need to send traffic from a host in the 10.10.10/24 network to a host in the 192.168.168/24 network. For route-based VPNs, traffic can be initiated by the SRX Series device through the tunnel. I recommend that when testing IPsec tunnels, test traffic be sent from a separate device on one side of the VPN to a second device on the other side of the VPN. For example, initiate a ping from 10.10.10.10 to 192.168.168.10.

     Troubleshooting is best performed on the peer using the responder role.

    Verifying the IKE Phase 1 Status

    From operational mode, enter the show security ike security-associations command. After obtaining an index number from the command, use the show security ike security-associations index index_number detail command.

    user@host> show security ike security-associations
    Index   Remote Address  State  Initiator cookie  Responder cookie  Mode
    1       2.2.2.2         UP     744a594d957dd513  1e1307db82f58387  Main
    user@host> show security ike security-associations index 1 detail
    IKE peer 2.2.2.2, Index 1,
      Role: Responder, State: UP
      Initiator cookie: 744a594d957dd513, Responder cookie: 1e1307db82f58387
      Exchange type: Main, Authentication method: Pre-shared-keys
      Local: 1.1.1.2:500, Remote: 2.2.2.2:500
      Lifetime: Expires in 28570 seconds
      Algorithms:
       Authentication        : sha1
       Encryption            : aes-cbc (128 bits)
       Pseudo random function: hmac-sha1
      Traffic statistics:
       Input bytes    :                 852
       Output bytes   :                 940
       Input packets  :                   5
       Output packets :                   5
      Flags: Caller notification sent
      IPSec security associations: 1 created, 0 deleted
      Phase 2 negotiations in progress: 0

    The show security ike security-associations command lists all active IKE Phase 1 SAs. If no SAs are listed, there was a problem with Phase 1 establishment. Check the IKE policy parameters and external interface settings in your configuration.

    If SAs are listed, review the following information:

    • Index—This value is unique for each IKE SA, which you can use in the show security ike security-associations index detail command to get more information about the SA.
    • Remote Address—Verify that the remote IP address is correct.
    • State
      • UP—The Phase 1 SA has been established.
      • DOWN—There was a problem establishing the Phase 1 SA.
    • Mode—Verify that the correct mode is being used.

    Verify that the following are correct in your configuration:

    • External interfaces (the interface must be the one that receives IKE packets)
    • IKE policy parameters
    • Preshared key information
    • Phase 1 proposal parameters (must match on both peers)

    The show security ike security-associations index 1 detail command lists additional information about the security association with an index number of 1:

    • Authentication and encryption algorithms used
    • Phase 1 lifetime
    • Traffic statistics (can be used to verify that traffic is flowing properly in both directions)
    • Role information
    • Initiator and responder information
    • Number of IPsec SAs created
    • Number of Phase 2 negotiations in progress

    Verifying the IPsec Phase 2 Status

    From operational mode, enter the show security ipsec security-associations command. After obtaining an index number from the command, use the show security ipsec security-associations index index_number detail command.

    user@host> show security ipsec security-associations
      total configured sa: 2
      ID    Gateway          Port  Algorithm          SPI      Life:sec/kb  Mon vsys
      <16384 2.2.2.2         500   ESP:aes-128/sha1   76d64d1d 3363/ unlim   -   0
      >16384 2.2.2.2         500   ESP:aes-128/sha1   a1024ee2 3363/ unlim   -   0
    user@host> show security ipsec security-associations index 16384 detail
      Virtual-system: Root
      Local Gateway: 1.1.1.2, Remote Gateway: 2.2.2.2
      Local Identity: ipv4_subnet(any:0,[0..7]=10.10.10.0/24)
      Remote Identity: ipv4_subnet(any:0,[0..7]=192.168.168.0/24)
        DF-bit: clear
    
        Direction: inbound, SPI: 1993755933, AUX-SPI: 0
        Hard lifetime: Expires in 3352 seconds
        Lifesize Remaining: Unlimited
        Soft lifetime: Expires in 2775 seconds
        Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
        Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc (128 bits)    
        Anti-replay service: enabled, Replay window size: 32
    
        Direction: outbound, SPI: 2701283042, AUX-SPI: 0
        Hard lifetime: Expires in 3352 seconds
        Lifesize Remaining: Unlimited
        Soft lifetime: Expires in 2775 seconds
        Mode: tunnel, Type: dynamic, State: installed, VPN Monitoring: -
        Protocol: ESP, Authentication: hmac-sha1-96, Encryption: aes-cbc
     (128 bits)    
        Anti-replay service: enabled, Replay window size: 32

    The output from the show security ipsec security-associations command lists the following information:

    • The ID number is 16384. Use this value with the show security ipsec security-associations index command to get more information about this particular SA.
    • There is one IPsec SA pair using port 500, which indicates that no NAT-traversal is implemented. (NAT-traversal uses port 4500 or another random high-number port.)
    • The SPIs, lifetime (in seconds), and usage limits (or lifesize in KB) are shown for both directions. The 3363/ unlim value indicates that the Phase 2 lifetime expires in 3363 seconds, and that no lifesize has been specified, which indicates that it is unlimited. Phase 2 lifetime can differ from Phase 1 lifetime, as Phase 2 is not dependent on Phase 1 after the VPN is up.
    • VPN monitoring is not enabled for this SA, as indicated by a hyphen in the Mon column. If VPN monitoring is enabled, U indicates that monitoring is up, and D indicates that monitoring is down.
    • The virtual system (vsys) is the root system, and it always lists 0.

    The output from the show security ipsec security-associations index 16384 detail command lists the following information:

    • The local identity and remote identity make up the proxy ID for the SA.A proxy ID mismatch is one of the most common causes for a Phase 2 failure. If no IPsec SA is listed, confirm that Phase 2 proposals, including the proxy ID settings, are correct for both peers. For route-based VPNs, the default proxy ID is local=0.0.0.0/0, remote=0.0.0.0/0, and service=any. Issues can occur with multiple route-based VPNs from the same peer IP. In this case, a unique proxy ID for each IPsec SA must be specified. For some third-party vendors, the proxy ID must be manually entered to match.
    • Another common reason for Phase 2 failure is not specifying the ST interface binding. If IPsec cannot complete, check the kmd log or set traceoptions.

    Reviewing Statistics and Errors for an IPsec Security Association

    From operational mode, enter the show security ipsec statistics index index_number command, using the index number of the VPN for which you want to see statistics.

    user@host> show security ipsec statistics index 16384
    ESP Statistics:
      Encrypted bytes:              920
      Decrypted bytes:             6208
      Encrypted packets:              5
      Decrypted packets:             87
    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

    You can also use the show security ipsec statistics command to review statistics and errors for all SAs.

    To clear all IPsec statistics, use the clear security ipsec statistics command.

    If you see packet loss issues across a VPN, you can run the show security ipsec statistics or show security ipsec statistics detail command several times to confirm that the encrypted and decrypted packet counters are incrementing. You should also check whether the other error counters are incrementing.

    Testing Traffic Flow Across the VPN

    You can use the ping command from the SRX Series device to test traffic flow to a remote host PC. Make sure that you specify the source interface so that the route lookup is correct and the appropriate security zones are referenced during policy lookup.

    From operational mode, enter the ping command.

    user@host> ping 10.10.10.10 from ethernet0/6
    Type escape sequence to abort
    Sending 5, 100-byte ICMP Echos to 10.10.10.10, timeout is 1 seconds from ethernet0/6
    !!!!!
    Success Rate is 100 percent (5/5), round-trip time min/avg/max=4/4/5 ms

    If the ping command fails from the SRX Series, there might be a problem with the routing, security policies, end host, or encryption and decryption of ESP packets.

    So check all the parameters configured above once again and reconfigure if problem continues.  You can use below tool for generating the configuration for SRX series l2l VPN Configurations.

    http://www.juniper.net/customers/support/configtools/vpnconfig.html

    So Thats it..happy configuration.. 🙂

     

    —————————————————————————————————————————-

    If you feel this article helped you to get some learning, please support by clicking below.

    paypal-button

LAN-to-LAN VPN Configuration in ASA (Ver 8.4 and above)

Tags

, , , , , ,

     As many of you are aware ASA 8.4 has been released recently. It contains many long awaited features, among them many changes/improvements to IPsec VPN.

A few days later I received an querry from a friend asking me, what happened to IPsec in 8.4. Good question and here you go..

Of course first thing notices is that there is no longer “isakmp” keyword, it was substituted by “ikev1”. But i have used in this article some “isakmp” words but dont worry go on..

IPsec-Sample-diagram

Configuring Interfaces

Step 1 To enter Interface configuration mode, in global configuration mode enter the interface command with the default name of the interface to configure. In the following example the interface is ethernet0.

hostname(config)# interface ethernet0/0
hostname(config-if)#

Step 2 To set the IP address and subnet mask for the interface, enter the ip address command. In the following example the IP address is 10.10.4.100 and the subnet mask is 255.255.0.0.

hostname(config-if)# ip address 10.10.4.100 255.255.0.0
hostname(config-if)#

Step 3 To name the interface, enter the nameif command, maximum of 48 characters. You cannot change this name after you set it. In the following example the name of the ethernet0 interface is outside.

hostname(config-if)# nameif outside
hostname(config-if)##

Step 4 To enable the interface, enter the no version of the shutdown command. By default, interfaces are disabled.

hostname(config-if)# no shutdown
hostname(config-if)#

Step 5 To save your changes, enter the write memory command.

hostname(config-if)# write memory
hostname(config-if)#

Step 6 To configure a second interface, use the same procedure.

Configuring ISAKMP Policy and Enabling ISAKMP on the Outside Interface

The ASA supports IKEv1 for connections from the legacy Cisco VPN client, and IKEv2 for the AnyConnect VPN client.

To set the terms of the ISAKMP negotiations, you create an IKE policy, which includes the following:

•The authentication type required of the IKEv1 peer, either RSA signature using certificates or preshared key (PSK).

•An encryption method, to protect the data and ensure privacy.

•A Hashed Message Authentication Codes (HMAC) method to ensure the identity of the sender, and to ensure that the message has not been modified in transit.

•A Diffie-Hellman group to determine the strength of the encryption-key-determination algorithm. The ASA uses this algorithm to derive the encryption and hash keys.

•For IKEv2, a separate pseudo-random function (PRF) used as the algorithm to derive keying material and hashing operations required for the IKEv2 tunnel encryption, etc.

•A limit to the time the ASA uses an encryption key before replacing it.

With IKEv1 policies, for each parameter, you set one value. For IKEv2, you can configure multiple encryption and authentication types, and multiple integrity algorithms for a single policy. The ASA orders the settings from the most secure to the least secure and negotiates with the peer using that order. This allows you to potentially send a single proposal to convey all the allowed transforms instead of the need to send each allowed combination as with IKEv1.

Configuring ISAKMP Policies for IKEv1 Connections

To configure ISAKMP policies for IKEv1 connections, use the crypto ikev1 policy command to enter IKEv1 policy configuration mode where you can configure the IKEv1 parameters:

crypto ikev1 policy priority

Step 1 Enter IPsec IKEv1 policy configuration mode. For example:

hostname(config)# crypto ikev1 policy 1
hostname(config-ikev1-policy)#

Step 2 Set the authentication method. The following example configures a preshared key:

hostname(config-ikev1-policy)# authentication pre-share
hostname(config-ikev1-policy)#

Step 3 Set the encryption method. The following example configures 3DES:

hostname(config-ikev1-policy)# encryption 3des
hostname(config-ikev1-policy)#

Step 4 Set the HMAC method. The following example configures SHA-1:

hostname(config-ikev1-policy)# hash sha
hostname(config-ikev1-policy)#

Step 5 Set the Diffie-Hellman group. The following example configures Group 2:

hostname(config-ikev1-policy)# group 2
hostname(config-ikev1-policy)#

Step 6 Set the encryption key lifetime. The following example configures 43,200 seconds (12 hours):

hostname(config-ikev1-policy)# lifetime 43200
hostname(config-ikev1-policy)#

Step 7 Enable IKEv1 on the interface named outside:

hostname(config)# crypto ikev1 enable outside
hostname(config)#

Step 8 To save your changes, enter the write memory command:

hostname(config)# write memory
hostname(config)#

Configuring ISAKMP Policies for IKEv2 Connections

To configure ISAKMP policies for IKEv2 connections, use the crypto ikev2 policy command to enter IKEv2 policy configuration mode where you can configure the IKEv2 parameters:

crypto ikev2 policy priority

Step 1 Enter IPsec IKEv2 policy configuration mode. For example:

hostname(config)# crypto ikev2 policy 1
hostname(config-ikev2-policy)#

Step 2 Set the encryption method. The following example configures 3DES:

hostname(config-ikev2-policy)# encryption 3des
hostname(config-ikev2-policy)#

Step 3 Set the Diffie-Hellman group. The following example configures Group 2:

hostname(config-ikev2-policy)# group 2
hostname(config-ikev2-policy)#

Step 4 Set the pseudo-random function (PRF) used as the algorithm to derive keying material and hashing operations required for the IKEv2 tunnel encryption. The following example configures SHA-1 (an HMAC variant):

hostname(config-ikev12-policy)# prf sha
hostname(config-ikev2-policy)#

Step 5 Set the encryption key lifetime. The following example configures 43,200 seconds (12 hours):

hostname(config-ikev2-policy)# lifetime 43200
hostname(config-ikev2-policy)#

Step 6 Enable IKEv2 on the interface named outside:

hostname(config)# crypto ikev2 enable outside
hostname(config)#

Step 7 To save your changes, enter the write memory command:

hostname(config)# write memory
hostname(config)#

Creating an IKEv1 Transform Set

An IKEv1 transform set combines an encryption method and an authentication method. During the IPsec security association negotiation with ISAKMP, the peers agree to use a particular transform set to protect a particular data flow. The transform set must be the same for both peers.

A transform set protects the data flows for the access list specified in the associated crypto map entry. You can create transform sets in the ASA configuration, and then specify a maximum of 11 of them in a crypto map or dynamic crypto map entry

Valid Encryption and Authentication Methods

Valid Encryption Methods Valid Authentication Methods
esp-des esp-md5-hmac
esp-3des (default) esp-sha-hmac (default)
esp-aes (128-bit encryption)
esp-aes-192
esp-aes-256
esp-null

Tunnel Mode is the usual way to implement IPsec between two ASAs that are connected over an untrusted network, such as the public Internet. Tunnel mode is the default and requires no configuration.

To configure a transform set, perform the following steps:

Step 1 In global configuration mode enter the crypto ipsec ikev1 transform-set command. The following example configures a transform set with the name FirstSet, esp-3des encryption, and esp-md5-hmac authentication. The syntax is as follows:

crypto ipsec ikev1 transform-set transform-set-name encryption-method authentication-method

hostname(config)# crypto ipsec transform-set FirstSet esp-3des esp-md5-hmac
hostname(config)#

Step 2 Save your changes.

hostname(config)# write memory
hostname(config)#

Creating an IKEv2 Proposal

For IKEv2, you can configure multiple encryption and authentication types, and multiple integrity algorithms for a single policy. The ASA orders the settings from the most secure to the least secure and negotiates with the peer using that order. This allows you to potentially send a single proposal to convey all the allowed transforms instead of the need to send each allowed combination as with IKEv1.

 

IKEv2 Encryption and Integrity Methods

 

Valid Encryption Methods Valid Integrity Methods
des sha (default)
3des (default) md5
aes
aes-192
aes-256

To configure an IKEv2 proposal, perform the following steps:

Step 1 In global configuration mode, use the crypto ipsec ikev2 ipsec-proposal command to enter ipsec proposal configuration mode where you can specify multiple encryption and integrity types for the proposal. In this example, secure is the name of the proposal:

hostname(config)# crypto ipsec ikev2 ipsec-proposal secure
hostname(config-ipsec-proposal)#

Step 2 Then enter a protocol and encryption types. ESP is the only supported protocol. For example:

hostname(config-ipsec-proposal)# protocol esp encryption 3des aes des
hostname(config-ipsec-proposal)#

Step 3 Enter an integrity type. For example:

hostname(config-ipsec-proposal)# protocol esp integrity sha-1
hostname(config-ipsec-proposal)#

Step 4 Save your changes.

Configuring an ACL

The adaptive security appliance uses access control lists to control network access. By default, the adaptive security appliance denies all traffic. You need to configure an ACL that permits traffic. An ACL for VPN traffic uses the translated address

To configure an ACL, perform the following steps:

Step 1 Enter the access-list extended command. The following example configures an ACL named l2l_list that lets traffic from IP addresses in the 192.168.0.0 network travel to the 150.150.0.0 network. The syntax isaccess-list listname extended permit ip source-ipaddress source-netmask destination-ipaddress destination-netmask.

hostname(config)# access-list l2l_list extended permit ip 192.168.0.0 255.255.0.0 
150.150.0.0 255.255.0.0
hostname(config)#

Step 2 Configure an ACL for the ASA on the other side of the connection that mirrors the ACL above. In the following example the prompt for the peer is hostname2.

hostname2(config)# access-list l2l_list extended permit ip 150.150.0.0 255.255.0.0 
192.168.0.0 255.255.0.0
hostname(config)#

Defining a Tunnel Group

A tunnel group is a set of records that contain tunnel connection policies. You configure a tunnel group to identify AAA servers, specify connection parameters, and define a default group policy. The ASA stores tunnel groups internally.

There are two default tunnel groups in the ASA: DefaultRAGroup, which is the default IPsec remote-access tunnel group, and DefaultL2Lgroup, which is the default IPsec LAN-to-LAN tunnel group. You can modify them but not delete them.

You can also create one or more new tunnel groups to suit your environment. The ASA uses these groups to configure default tunnel parameters for remote access and LAN-to-LAN tunnel groups when there is no specific tunnel group identified during tunnel negotiation.

To establish a basic LAN-to-LAN connection, you must set two attributes for a tunnel group:

•Set the connection type to IPsec LAN-to-LAN.

•Configure an authentication method for the IP, in the following example, preshared key for IKEv1 and IKEv2.

To use VPNs, including tunnel groups, the ASA must be in single-routed mode. The commands to configure tunnel-group parameters do not appear in any other mode.

Step 1 To set the connection type to IPsec LAN-to-LAN, enter the tunnel-group command. The syntax is tunnel-group name type type, where name is the name you assign to the tunnel group, and type is the type of tunnel. The tunnel types as you enter them in the CLI are:

remote-access (IPsec, SSL, and clientless SSL remote access)

ipsec-l2l (IPsec LAN to LAN)

In the following example the name of the tunnel group is the IP address of the LAN-to-LAN peer, 10.10.4.108.

hostname(config)# tunnel-group 10.10.4.108 type ipsec-l2l
hostname(config)#

LAN-to-LAN tunnel groups that have names that are not an IP address can be used only if the tunnel authentication method is Digital Certificates and/or the peer is configured to use Aggressive Mode.

Step 2 To set the authentication method to preshared key, enter the ipsec-attributes mode and then enter the pre-shared-key command to create the preshared key. You need to use the same preshared key on both ASAs for this LAN-to-LAN connection.

The key is an alphanumeric string of 1-128 characters.

In the following example the IKEv1 preshared key is 44kkaol59636jnfx:

hostname(config)# tunnel-group 10.10.4.108 ipsec-attributes
hostname(config-tunnel-ipsec)# pre-shared-key 44kkaol59636jnfx

In the next example, the IKEv2 preshared key is configured also as 44kkaol59636jnfx:

hostname(config-tunnel-ipsec)# ikev2 local-authentication pre-shared-key 44kkaol59636jnfx

Step 3 Save your changes.

hostname(config)# write memory
hostname(config)#

Creating a Crypto Map and Applying It To an Interface

Crypto map entries pull together the various elements of IPsec security associations, including the following:

•Which traffic IPsec should protect, which you define in an access list.

•Where to send IPsec-protected traffic, by identifying the peer.

•What IPsec security applies to this traffic, which a transform set specifies.

•The local address for IPsec traffic, which you identify by applying the crypto map to an interface.

For IPsec to succeed, both peers must have crypto map entries with compatible configurations. For two crypto map entries to be compatible, they must, at a minimum, meet the following criteria:

•The crypto map entries must contain compatible crypto access lists (for example, mirror image access lists). If the responding peer uses dynamic crypto maps, the entries in the ASA crypto access list must be “permitted” by the peer’s crypto access list.

•The crypto map entries each must identify the other peer (unless the responding peer is using a dynamic crypto map).

•The crypto map entries must have at least one transform set in common.

If you create more than one crypto map entry for a given interface, use the sequence number (seq-num) of each entry to rank it: the lower the seq-num, the higher the priority. At the interface that has the crypto map set, the ASA evaluates traffic against the entries of higher priority maps first.

Enter these commands in global configuration mode:

Step 1 To assign an access list to a crypto map entry, enter the crypto map match address command.

The syntax is crypto map map-name seq-num match address aclname. In the following example the map name is abcmap, the sequence number is 1, and the access list name is l2l_list.

hostname(config)# crypto map abcmap 1 match address l2l_list
hostname(config)#

Step 2 To identify the peer (s) for the IPsec connection, enter the crypto map set peer command.

The syntax is crypto map map-name seq-num set peer {ip_address1 | hostname1}[… ip_address10 |hostname10]. In the following example the peer name is 10.10.4.108.

hostname(config)# crypto map abcmap 1 set peer 10.10.4.108
hostname(config)#

Step 3 To specify an IKEv1 transform set for a crypto map entry, enter the crypto map ikev1 set transform-setcommand.

The syntax is crypto map map-name seq-num ikev1 set transform-set transform-set-name.
In the following example the transform set name is FirstSet.

hostname(config)# crypto map abcmap 1 set transform-set FirstSet
hostname(config)#

Step 4 To specify an IKEv2 proposal for a crypto map entry, enter the crypto map ikev2 set ipsec-proposalcommand:

The syntax is crypto map map-name seq-num set ikev2 ipsec-proposal proposal-name.
In the following example the proposal name is secure.

hostname(config)# crypto map abcmap 1 set ikev2 ipsec-proposal secure
hostname(config)#

Applying Crypto Maps to Interfaces

You must apply a crypto map set to each interface through which IPsec traffic travels. The ASA supports IPsec on all interfaces. Applying the crypto map set to an interface instructs the ASA to evaluate all interface traffic against the crypto map set and to use the specified policy during connection or security association negotiations.

Step 1 To apply the configured crypto map to the outside interface, enter the crypto map interface command. The syntax is crypto map map-name interface interface-name.

hostname(config)# crypto map abcmap interface outside
hostname(config)#

Step 2 Save your changes.

hostname(config)# write memory
hostname(config)#

You are Done..!!!

 

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

Troubleshooting Firewall Session Establishment – Juniper SRX

Tags

, , , , , ,

Capture

1. Is the packet arriving on the SRX?

The first thing that we need to make sure is that the traffic is arriving on the SRX itself. We should be able to see the traffic by just viewing the output of the debug itself. This may not be the case if stateless firewall filters are being used, which may drop the packets before they are processed by the flow engine. If you don’t see the traffic arriving on the SRX, you should check the routing table of the peer device, as well as checking to see if the peer device has an ARP entry for the IP address we are trying to reach. This is particularly important if you are using static NAT, as Proxy ARP MAY be required.

2. Is the packet being blocked by a Screen?

 If a packet is an invalid packet, and screens are enabled on the source zone, it may be dropped. An example would be a packet that has a SYN, ACK, and FIN bits set.

3. Is the packet destined for the firewall itself?

 This is most common with management traffic such as telnet, ssh, and SNMP, but also for protocol traffic such as BGP, OSPF, RIP, and PIM. In this case, we must make sure that these respective services are running on that interface. In JUNOS, this is configured at either the zone or interface level under [edit security zones security-zone <zone> hostinbound- traffic] if this is not configured then the firewall will drop the packet.

4. Is the session asymmetric?

 Stateful SYN checking is on by default, and if the firewall does not see the SYN packet, it will drop the subsequent packets and the session will not establish. This should be clear from the debug. In this situation you must either ensure that the SRX is in the initial packet path so that it sees the SYN packet (recommended!) or turn off SYN checking. If the SRX cannot see both directions of the flow then some features such as IDP may not be able to work at the full capacity.

5. Is the packet from an existing session?

 If the packet matches an existing session then we will not include all debugging information in that output, just some basics, and we refer it to the session ID to cross reference. You can still examine the session table to track this session with the “show security flow session” command.

6. Is the packet arriving on the correct interface/zone?

 When looking at the debug output you should be able to tell what interface the packet has arrived on, and subsequently, what the source zone is. This is important for policy lookup, and if it is not matched properly, then most likely a problem will occur.

7. Is the appropriate route / L2 forwarding path being selected?

  Depending on if you are using Layer 3 more or Transparent mode, we will need to ensure that the appropriate forwarding decision is chosen. With layer 3 mode, the firewall will do a route lookup based on the destination of the route, which will determine what the egress interface will be (which also determines the to-zone,) if the device is in transparent mode, the device will either do an ARP, or will broadcast the packet out all interfaces (except that from which it came) in the same bridging domain. If the wrong route is set (in transparent mode, the forwarding decision should happen without intervention, unless other mechanisms such as Dynamic ARP inspection or L2 Broadcast filtering in place to block this) then we may chose the wrong outbound interface to send the traffic out, as well as the wrong NAT decision. Currently, we do not give a route-id in the output of the debug like we did in ScreenOS. This will probably change in the future. You may need to do a route lookup with the “show route <prefix>” command to make sure that the correct route is chosen and that the appropriate outbound interface and next-hop is selected. In transparent mode, you can check the L2 forwarding table with the “show arp” and “show ethernetswitching table” if using the branch SRX, while the High End SRX use a different command “show l2- learning interface” to see what entries are known by the system.

8. Is the correct policy being selected by the firewall?

 Now that we have determined what the appropriate egress interface / zone are supposed to be, assuming that those are correct, we need to make sure the correct firewall policy is being selected by the firewall. Today that number is referenced in the debug logs as “policy <#>” and as shown in the debug above, we can run the “show security policies | find “Index\: <#>” command to make sure that the policy is correct. If it is not the correct policy, you will need to take a look at the source/destination address and service. It is often prudent to look into the address and service objects themselves to make sure that they are really matching what you are looking for, and not just the names of the address objects themselves as shown in the policy. For instance, we could name an object 1.1.1.0/24, but the actual address that it matches if we omit the subnet mask wouldbe 1.1.1.0/32. Just by looking at the object name we may have it wrong. Also, see the next step about NAT configuration as it may impact your policy.

9. Is the correct NAT being applied by the policy?

 Today we have some improvements that are going to be put into NAT debugging, but for now, the best thing to check is to look at the output of the debug and see what translation takes place. Is it what you expect (e.g. is the source translated or not translated as expected? Is the destination translated or not translated as expected?) Remember that static translations happen before policy lookup, while source and destination translations occur AFTER policy lookup, so you need to make sure that you have factored this in when configuring your policy. If the wrong action is being taken on your policy, you may want to review the rulebase configuration to visually inspect the match and action criteria. There can be many NAT rulebases depending on the configuration, so be sure to take that into account.

10. Does the debug show that the packet is being processed by “Application Services” or is destined to a VPN tunnel?

 

 If the packet is being processed by application services then further debugging may be necessary, for instance, if you have IDP enabled on that policy, and the IDP detects that packet as malicious, it may drop it based upon policy (so even though the FW flow looked OK, it could still be dropped based upon policy) same is true for other UTM features, so you need to keep this in mind. If the packet is destined to a tunnel, then you should see this output. If a VPN is referenced, the VPN must be active, or else the packet will not have anywhere to go.

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button

Debug Flow Basic Utility in Netscreen FW

Tags

, , , , ,

The Debug utility can help troubleshooting traffic flow issues for many different traffic types.  Below you will find how to run debug flow basic as well as a few other debug options.

netscreen_5400_frontwtop_high

Many times, when contacting support, debugging information is requested to further troubleshoot a problem.  The following shows a brief procedure on obtaining debugging information:

  • Connect or Telnet to the Juniper Firewall device.
  • Turn on the dbuf buffer.  This sets up a portion of memory required to hold the debug information needed.

When troubleshooting the firewall, the output of the debug will be directed either to the console or to a buffer. Usually, the debugging information should go to the buffer, opposed to the console. When information is sent to the console, it is resource intensive, and can produce performance problems if too much debugging information is sent to the console. The alternative is sending the data to a buffer called dbuf.

From the command line interface (CLI): set console dbuf

  • Set the parameters for debugging.  This is important.  Specify what information is to be captured in the debug.  Capturing too much information can overload the CPU of the Firewall.  For additional information, consult: Understanding debug filters.

From the CLI:

fw-> set ffilter ?

dst-ip               flow filter dst ip
dst-port             flow filter dst port
ip-proto             flow filter ip proto
src-ip               flow filter src ip
src-port             flow filter src port
ns100-> set ffilter

These are the options available to filter a debug.

Example: Trying to find out why a PC, IP address 192.168.10.50, on the local network cannot get out to the Internet.  Set up a filter so the debug will show what happens when that PC tries to communicate to the Internet:

set ffilter src-ip 192.168.10.50

The Firewall will perform a debug on the data coming from the source IP of 192.168.10.50.

Note: Keep in mind that these parameters apply to the outermost IP header, so if the packets are encapsulated in a VPN tunnel, then you may not capture those packets in the tunnel, unless you also add filters for the VPN tunnel.

  • Turn on the debug flow.  This will display information related to the flow of traffic through the box.  There are three levels of debug flow:

basic
all
drop

For most cases, debug flow basic should be sufficient.  From the CLI:

debug flow basic 

Use debug flow drop command to see dropped or denied packets (including those that did not make it to the policy engine).  This will give you detailed information about all packets trying to pass through the firewall, but for some reason is dropped.  Logs on the policy will only get logged if a session is completed.  This debug will give you dropped information, just in case a session does not get created.

debug flow drop

  • After traffic has flowed through the firewall, and failed, turn off the debug.  Press the <esc> or from the CLI:

undebug all 

  • Obtain the output of the debug.  From the CLI:

Example fw-> get dbuf stream
12630.0: trust:172.16.10.144/1545->24.0.0.27/53,17
12630.0:   search acl set 0
12630.0:   Send to untrust
12630.0: icmp embed ip: 24.0.0.27/53->172.16.10.144/1545,17
12630.0: untrust:24.0.0.27/53->172.16.10.144/1545,17
12630.0:   Send to trust
12630.0: untrust:24.0.0.27/53->172.16.10.144/1545,17
12630.0:   Send to trust
12630.0: trust:172.16.10.144/38400->204.71.200.75/256,1
12630.0:   search acl set 0
12630.0:   Send to untrust 

—————————————————————————————————————————-

If you feel this article helped you to get some learning, please support by clicking below.

paypal-button