Policy-Based vs Route-Based VPN

Policy-Based vs Route-Based VPNs: Part 1

By Zeeshan | Sunday, December 28, 2014 at 11:05 p.m. 

This is the first part of a two-part post that will compare and contrast policy-based VPNs and route-based VPNs. Policy-based VPNs encrypt and encapsulate a subset of traffic flowing through an interface according to a defined policy (an access list). The policy may dictate that only some or all of the traffic being evaluated is placed into the VPN. This type of VPN is often referred to as LAN-to-LAN when implemented on Cisco ASAs, and I have covered the ASA implementation before. This article examines the configuration of a policy-based VPN on Cisco IOS.

In contrast to a policy-based VPN, a route-based VPN employs routed tunnel interfaces as the endpoints of the virtual network. All traffic passing through a tunnel interface is placed into the VPN. Rather than relying on an explicit policy to dictate which traffic enters the VPN, static and/or dynamic IP routes are formed to direct the desired traffic through the VPN tunnel interface. IPsec quick and dirty provides a decent primer if you're not familiar with route-based VPNs on IOS.

The lab topology employed in this article is easily replicated using Dynamips or the community lab, and I encourage readers to play along in a lab of their own while reading. If you do, be sure to bookmark this VPN troubleshooting guide from Cisco before you begin. It can be a real time-saver should you run into a wall.

Topology

Our goal is to form two VPNs across the "public" network represented by the 172.16.0.0/15 space. (And before anyone brings up my New Year's pledge, I am planning to replicate both VPNs configurations using IPv6 in the future. I just wanted to keep the IP architecture as simple as possible for now since we're already dealing with two fairly complex topics.)

The first part of this article covers setting up a policy-based VPN between R1 and R3. The second part will cover the configuration of a route-based VPN tunnel between R1 and R5, and discuss some pros and cons to both approaches.

Step 1: Define an access list to match interesting traffic

This is the policy part of policy-based VPNs. We need to define an access list to match all the traffic we want to send through the VPN between the two routers. Every line in the access list will result in a bidirectional pair of IPsec security associations (SAs) between the VPN endpoints, so it's beneficial to be as succinct as possible when creating a policy.

For our purposes, we only need to match traffic between the two LANs attached to R1 and R3. Specifically, we need to match traffic from 10.0.1.0/24 to 10.0.3.0/24 on R1, and from 10.0.3.0/24 to 10.0.1.0/24 on R3. This results in two ACLs which mirror each other, one on either router.

R1

ip access-list extended R1_to_R3
 permit ip 10.0.1.0 0.0.0.255 10.0.3.0 0.0.0.255

R3

ip access-list extended R3_to_R1
 permit ip 10.0.3.0 0.0.0.255 10.0.1.0 0.0.0.255

Note that these ACLs must mirror each other exactly in order for the IPsec SAs to form correctly. This is easy when we only have one permit statement, but can become burdensome when dealing with numerous policy entries.

Step 2: Create a pre-shared key

To keep things simple, we'll configure the routers to authenticate one another (via ISAKMP) using a pre-shared key. In the real world, public key authentication provides much better security.

We'll create a keyring to hold our pre-shared keys, which are mapped by peer (public) IP address. R1 maps the key string MySecretKey to R3, and vice versa.

R1

crypto keyring VPN 
  pre-shared-key address 172.16.0.3 key MySecretKey

R3

crypto keyring VPN 
  pre-shared-key address 172.16.0.1 key MySecretKey

Step 3: Create an ISAKMP policy

Next we'll create an ISAKMP policy. This sets the parameters which will be used by the routers during IKE phase one, when the initial asymmetrically-encrypted ISAKMP SA is negotiated. The policy below employs 256-bit AES using pre-shared key authentication (from step two) and Diffie-Hellman group five.

This policy is applied identically to both routers.

R1 and R3:

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

Step 4: Create an ISAKMP profile

An ISAKMP profile is used to establish parameters for a particular ISAKMP peer by matching its outside IP address. We specify the keyring to be used for this peer so that the router knows how to locate the correct pre-shared key.

R1

crypto isakmp profile R1_to_R3
   keyring VPN
   match identity address 172.16.0.3 255.255.255.255

R3

crypto isakmp profile R3_to_R1
   keyring VPN
   match identity address 172.16.0.1 255.255.255.255

Step 5: Define an IPsec transform-set

Now that ISAKMP is out of the way, we move on to IPsec configuration, which is much less involved: We simply need to define an IPsec transform-set. A transform-set tells the router what protocol, encryption, and hashing algorithms to use when forming the IPsec SAs, as well as in which mode to operate (tunnel or transport) and a few other details. The line below defines a transform-set employing ESP with 256-bit AES and SHA-1 hashing (similar to our ISAKMP policy) in tunnel mode. Create the same transform-set on both routers.

R1 and R3

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

Step 6: Create and apply the crypto map

Finally, we tie together all of these pieces by creating a crypto map, which does a few things. In order of the config snippets presented below, these are:

• Matches "interesting" traffic based on the access list we created in step one
• Sets the remote peer to the outside IP address of the remote router
• Sets the transform-set we defined in step five
• Sets the ISAKMP profile we defined in step four
• Enables static reverse-route injection, which creates static routes for the remote networks specified by the matched access list
• Sets the administrative distance of the injected static routes to ten (optional)

After creating the crypto map, apply it to the appropriate interface on each router.

R1

crypto map Policy_VPN 10 ipsec-isakmp
 match address R1_to_R3
 set peer 172.16.0.3
 set transform-set ESP-AES256-SHA1
 set isakmp-profile R1_to_R3
 reverse-route static
 set reverse-route distance 10
!
interface FastEthernet0/0
 crypto map Policy_VPN

R3

crypto map Policy_VPN 10 ipsec-isakmp
 match address R3_to_R1
 set peer 172.16.0.1
 set transform-set ESP-AES256-SHA1
 set isakmp-profile R3_to_R1
 reverse-route static
 set reverse-route distance 10
!
interface FastEthernet0/0
 crypto map Policy_VPN

Our policy VPN configuration is complete! We can verify that the crypto map has injected a static route on R1 for the 10.0.3.0/24 network on R3. (Note that the static parameter of the reverse-route command causes the route to be injected even when the VPN tunnel is not established.)

R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
S       10.0.3.0 [10/0] via 172.16.0.3
C       10.0.1.0 is directly connected, Loopback1

Testing

Policy VPNs by nature are created on-demand when traffic which matches the associated policy (access list) is detected egressing an interface to which the crypto map is applied. Currently, there are no existing ISAKMP SAs:

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status

IPv6 Crypto ISAKMP SA

We can generate some traffic to trigger the creation of the VPN by performing a simple ping whose source anddestination addresses are matched by the VPN policy:

R1# ping 10.0.3.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1
.!!!!
Success rate is 80 percent (4/5), round-trip min/avg/max = 1/3/4 ms

Notice that the first packet was dropped while the VPN was established. The next four pings succeeded, and we can verify that an ISAKMP SA was established. We can also verify the creation of IPsec SAs with the commandshow crypto ipsec sa.

R1# show crypto isakmp sa        
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.16.0.3      172.16.0.1      QM_IDLE           4003 ACTIVE

IPv6 Crypto ISAKMP SA

Successive pings will all succeed so long as the VPN tunnel doesn't time-out.

R1# ping 10.0.3.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.3.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

That about wraps it up for simple policy-based VPNs. In part two, we'll look at the configuration of a comparable route-based VPN and examine the pros and cons of each approach.

Policy-Based vs Route-Based VPNs: Part 2

By Zeeshan | Sunday, December 28, 2014 at 11:05 p.m. 

This article is a continuation of our discussion regarding policy-based versus route-based VPNs. Make sure to read through part one before continuing if you haven't already. In this second part, we'll look at configuring a route-based VPN on IOS and then examine some important differences between the two approaches.

Step 1: Create a pre-shared key

Route-based VPNs don't rely on an explicit policy (access list) to match traffic, so we can skip that step and start by creating a pre-shared key. On R1, we can re-use the keyring we defined in part one and simply add a new key for R5. On R5, create a new keyring and key for R1. (Use the same key on both routers.)

R1

crypto keyring VPN 
  pre-shared-key address 172.16.0.3 key MySecretKey
  pre-shared-key address 172.17.0.5 key AnotherSecretKey

R5

crypto keyring VPN
  pre-shared-key address 172.17.0.1 key AnotherSecretKey

Step 2: Create an ISAKMP policy

We can also re-use the ISAKMP policy we created on R1 in part one; just remember to apply it to R5.

R1 and R5

crypto isakmp policy 10
 encr aes 256
 authentication pre-share
 group 5

Step 3: Create an ISAKMP profile

This step should also look familiar. Create a new ISAKMP profile on both R1 and R5 to match the peer IP address to the pre-shared key keyring. (R1 will now have two ISAKMP profiles, R1_to_R3 and R1_to_R5.)

R1

crypto isakmp profile R1_to_R5
   keyring VPN
   match identity address 172.17.0.5 255.255.255.255 

R5

crypto isakmp profile R5_to_R1
   keyring VPN
   match identity address 172.17.0.1 255.255.255.255 

Step 4: Define an IPsec transform-set

We can also re-use the IPsec transform-set defined on R1. Be sure to define it on R5 as well.

R1 and R5

crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac

Step 5: Create an IPsec profile

At this point we start doing things a bit differently. We need to create an IPsec profile, which serves as a wrapper around one or more transform-sets and other parameters to be used in the construction of IPsec SAs. (For our purposes, we only need to reference a single transform-set, so it probably appears redundant.) Create the IPsec profile on both R1 and R5.

R1 and R5

crypto ipsec profile Routed_VPN
 set transform-set ESP-AES256-SHA1 

Step 6: Create a VPN tunnel interface

Now we get into the meat of the VPN configuration. We need to create a routed tunnel interface on both routers to act as the logical VPN edge. Tunnel interfaces serve to encapsulate/encrypt egressing traffic and decapsulate/decrypt ingressing traffic. (Here's a way to visualize this concept if it's a bit fuzzy.)

We'll use the 192.168.0.0/30 network for our VPN tunnel. The tunnel source and destination addresses are defined as the local and remote outside router IP addresses, respectively. The last two lines of the configs below apply IPsec to the tunnel interface using the IPsec profile we defined in the previous step.

R1

interface Tunnel0
 ip address 192.168.0.1 255.255.255.252
 tunnel source 172.17.0.1
 tunnel destination 172.17.0.5
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Routed_VPN

R5

interface Tunnel0
 ip address 192.168.0.2 255.255.255.252
 tunnel source 172.17.0.5
 tunnel destination 172.17.0.1
 tunnel mode ipsec ipv4
 tunnel protection ipsec profile Routed_VPN

Notice that, unlike our policy VPN configuration, the peer LAN (10.0.5.0/24) is not automatically injected by the VPN because there is no policy to tell the router what exists on the other side of the tunnel:

R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/24 is subnetted, 2 subnets
S       10.0.3.0 [10/0] via 172.16.0.3
C       10.0.1.0 is directly connected, Loopback1
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0

Also unlike policy-based VPNs, the SAs for a route-based VPN are constructed automatically and maintained indefinitely whether or not traffic is passing across the VPN.

R1# show crypto isakmp sa
IPv4 Crypto ISAKMP SA
dst             src             state          conn-id status
172.17.0.5      172.17.0.1      QM_IDLE           4004 ACTIVE
172.16.0.3      172.16.0.1      QM_IDLE           4003 ACTIVE

Step 7: Enable dynamic routing

As just mentioned, route-based VPNs have no mechanism to automatically discover the remote networks which are reachable over the VPN. So how do we communicate this information among peers? With a routing protocol, of course! Just about any routing protocol will do; we'll use single-area OSPF for this lab.

OSPF must be enabled for both the internal LAN interface (which in this case is actually just a loopback pretending to be a /24 network) and the tunnel interface. An OSPF adjacency should form between R1 and R5 over the 192.168.0.0/30 network, inside the VPN. There is no need to enable OSPF on the outside network (172.17.0.0/16), which we're pretending is publicly routed space outside of the VPN (e.g. the Internet).

R1 and R5

router ospf 1
!
interface Loopback1
 ip ospf 1 area 0
!
interface Tunnel0
 ip ospf 1 area 0

Testing

R1 and R5 should learn of each other's LAN prefixes via OSPF, and both networks should be immediately reachable via through the VPN tunnel:

R1# show ip route
Codes: C - connected, S - static, R - RIP, M - mobile, B - BGP
       D - EIGRP, EX - EIGRP external, O - OSPF, IA - OSPF inter area 
       N1 - OSPF NSSA external type 1, N2 - OSPF NSSA external type 2
       E1 - OSPF external type 1, E2 - OSPF external type 2
       i - IS-IS, su - IS-IS summary, L1 - IS-IS level-1, L2 - IS-IS level-2
       ia - IS-IS inter area, * - candidate default, U - per-user static route
       o - ODR, P - periodic downloaded static route

Gateway of last resort is not set

172.17.0.0/24 is subnetted, 1 subnets
C       172.17.0.0 is directly connected, FastEthernet0/1
     172.16.0.0/24 is subnetted, 1 subnets
C       172.16.0.0 is directly connected, FastEthernet0/0
     10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks
S       10.0.3.0/24 [10/0] via 172.16.0.3
C       10.0.1.0/24 is directly connected, Loopback1
O       10.0.5.1/32 [110/1001] via 192.168.0.2, 00:01:29, Tunnel0
     192.168.0.0/30 is subnetted, 1 subnets
C       192.168.0.0 is directly connected, Tunnel0
R1# ping 10.0.5.1 source 10.0.1.1

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 10.0.5.1, timeout is 2 seconds:
Packet sent with a source address of 10.0.1.1 
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 1/3/4 ms

Pros and Cons

If you've been paying close attention throughout these last two articles, you'll have noticed a number of subtle but important differences between policy-based and route-based VPNs.

Policy-based VPNs require administrative policy maintenance

This is probably the biggest drawback of using policy-based VPNs as configured in part one. If we wanted to add a second internal network to R3, for example, we would have to manually update the policy ACL on both R1 and R3 to match traffic for the new network. This isn't a big deal if you're only ever going to manage a handful of networks, but the burden can quickly grow tiring when managing several dozen VPN sites.

Policy-based VPNs result in excessive IPsec SA creation

On the heels of the first observation, we realize that every ACL entry in a VPN policy results in a distinct pair of IPsec SAs (which we can examine in detail with the command show crypto ipsec sa). This isn't a problem if you can efficiently summarize routes, but results in substantial overhead if you have to define a number of distinct routes at either end of the VPN.

Some devices only support policy-based VPNs

I'm looking at you, ASAs. Some devices simply don't support tunnel interfaces or route-based VPNs, making the choice to adopt policy-based VPNs rather easy.

Route-based VPNs require a routed subnet

While route-based VPNs require only a single pair of IPsec SAs, they accomplish this because the VPN tunnel is constructed as an independently routed link (192.168.0.0/30 in our example). Rather than having to match all possible source and destination addresses in the private networks, a pair of IPSec SAs is built only to match traffic between the tunnel source and destination outside IPs. The trade-off, of course, is that we need to assign additional IP address space to the tunnel links.

Route-based VPNs are always on

The SAs for a route-based VPN are always maintained, so long as the corresponding tunnel interface is up. This is in contrast to a policy-based VPN, which forms SAs in response to detecting traffic which matches the policy (and will eventually tear down the SAs in the absence of such traffic). This can be seen as a benefit of policy-based VPNs if your VPN experiences infrequent traffic load, but personally I prefer to have my crypto tunnels up all the time to avoid IKE negotiation delay.

Route-based VPNs require a routing protocol

We saw in part one that reverse route injection can be used in a policy-based VPN to automatically inject static routes for destinations reachable via the VPN tunnel. Route-based VPNs require the introduction of a separate dynamic routing protocol (or static routes) to distribute VPN routing information among peers.

Overall, I think it's fair to say that route-based VPNs offer a much more robust and versatile VPN solution than the policy-based VPN configuration we examined in part one. (And that's not even taking into consideration more scalable route-based VPN solutions like DMVPN.) But I'm curious to hear what readers prefer: policy-based or route-based? Leave a comment and let everyone know!

Fortigate Site to Site VPN

Fortigate Site to Site VPN

I would like to add some more simple configuration, this time VPN Site to Site between a Fortigate and a CheckPoint firewalls, 

For an ease of access I'll split this to two parts, so let's start with the easier, the Forti :

So, first thing – create an address object for the LAN of the NGX

With that out of the way create Phase 1, I used DES for encryption and MD5 for authentication, feel free to change it as you wish, I matched the keylife to Checkpoint's default settings

Now, phase 2 make sure to specify the source and destination for the tunnel – may cause problems if it's set to any.

And last thing to do is a rule to allow the actual tunnel,

 from internal to external action "ipsec" and choose the tunnel.

And that's it for the fortigate side.

Firewall has a 3-way connection establishment handshake

Firewall has a 3-way connection establishment handshake, and a pair of 2-way close handshakes.

The PIX, like many other professional firewalls, is a stateful firewall. Essentially, this means that the PIX actively monitors all connection oriented traffic (mainly TCP), and builds a connection table (or database) that it uses to keep track of active sessions. Depending on where you set your buffer logging, you can see both the building and teardown of TCP connections that traverse the firewall. For example, you may have a user opening up an FTP session from the inside of your network out to the internet somewhere. In this case, you will see the PIX log a message like:

Built outbound tcp connection for IP address/source port to IP Address/21... (word order not exact, but you get the idea)

This log message indicates the start of the 3-way handshake process (it does not mean that it worked, however...)

You can now do a "show conn" on the PIX command line, and you should see a line in there for this particular TCP session. The destination port would be 21, since this is an FTP. Also, there are some flags at the end of the line. If the connection was successful, you will see a capital U (for Up, meaning the 3-way handshake was successful). If you have any a's or s's (small or upper case), then something didn't work, and you are most likely in a SYN-Sent state, waiting for the remote Ack-SYN. That's a whole other conversation though...

Back to the topic - let's say that this connection failed, perhaps the remote FTP server is down. The PIX has some Global connection timeout values. The default value for a half-open, (embryonic) connection is 2 minutes. If the remote server doesn't send the ACK-SYN back to the initial connection establishment, then the PIX will clear the connection from it's table, and log a connection teardown message.

There are about 3 or 4 types of teardown messages that can be logged (if memory serves me). At the very end of the log entry there is a reason. Some of them are:
FINs
TCP-Reset-O
TCP-Reset-I
Conn-Timeout
Deny

There may be others, but you'd have to check the PIX docs to see (if it's even in there...)

I know you're going to ask, so here is what each one means:

FINs - this represents a normal close - in other words the two systems talking to each other mutually agreed to close the session. This is normal behavior.

TCP-Reset-O (or I): Another way that a TCP session can be closed is for one of the parties to send a TCP-Reset. This is essentially a packet that tells the other side that "I'm hanging up on you". It's the TCP/IP equivalent to when you really piss off your girlfriend, and she slams down the phone in your ear. The difference between the I and the O has to do with the interface the reset was heard from. If it's an I, it means inside - but not necessarily the actual inside interface... it's the interface that has the higher security value of the two interfaces being used to build the connection in question. If it's an O, then it came from the lower security interface...

Conn-Timeout - just what you think - this refers back to the scenario I mentioned above with the FTP session and the remote server being down. After that 2 minute timer expires, the PIX will log the teardown with this as the reason. You will also see this if the PIX active connection idle timer expires too (default is 1 hour for that). And lastly, you can see this if the two systems fail to exchange the TCP-FIN process properly (normal close process). The normal close process, by the way, is simply a FIN packet from the system who is initiating the close request, and the other side is supposed to ACK the FIN (that's one pair). Now the session is 'half-closed'. Once the remote side is ready to close the connection too, it sends a FIN, and the other side should ACK it. Now it's fully closed. If part of this pair of 2-way handshake fail, then the connection according to the PIX is half closed (you'll see F flags in the show conn command output). The half-closed timer I believe is 5 minutes. If the connection doesn't close normally after that 5 minute counter expires, the PIX clears the connection from it's table and logs this conn-timeout reason in the teardown.

Lastly, there is 'Deny'. This one is seldomly observed. Generally, you would see it if a connection that was being application inspected (like FTP or http, for example), violated the fixup rulebase. The PIX would clear the connection and log the deny as the reason in the teardown message. I've seen really old FTP servers do this.

Anyway - I hope this clears things up a bit for you. If you are using the PIX for your business and you have a lot of traffic going through it, I highly recommend you learn more about the connection table, especially the flags at the end. The PIX can be a very powerful troubleshooting tool when the application clowns are telling you there is a network problem (the story of my life!). Between the logs and the connection flags, you can pretty much see what's going on at any given moment in time - excellent for real time troubleshooting - and tossing the problem back in their laps!

Juniper (SRX) Firewall Commands

Juniper SRX Firewalls

**********************
run = used in configure mode to use operational mode commands

//Show Routes
show route brief
show route best x.x.x.x
set routing-options static route 10.2.2.0/24 next-hop 10.1.1.254
//Forwarding Table
run show route forwarding-table destination x.x.x.x/24

//TraceOptions settings
root@fw1# show security flow | display set
set security flow traceoptions file matt_trace
set security flow traceoptions file files 3
set security flow traceoptions file size 100000
set security flow traceoptions flag basic-datapath
set security flow traceoptions packet-filter f0 source-prefix 10.0.0.1/32 destination-prefix 200.1.2.3/32
set security flow traceoptions packet-filter f1 source-prefix 10.0.0.1/32 destination-prefix 200.1.2.3/32
activate security flow traceoptions
commit
monitor start matt_trace
monitor list

!! Kill the capture
monitor stop
clear log             !! Clear the log file
delete security flow traceoptions
commit
file delete

//Show Traceoptions
show security flow session source-prefix 10.124.80.42 destination-prefix 117.1.1.25
start shell

egrep ‘matched filter|(ge|fe|reth)-.*->.*|session found|create session|dst_xlate|routed|search|denied|src_xlate|outgoing phy if’ /var/log/matt_trace | sed -e ‘s/.*RT://g’ | sed -e ‘s/tcp, flag 2 syn/–TCP SYN–/g’ | sed -e ‘s/tcp, flag 12 syn ack/–TCP SYN\/ACK–/g’ | sed -e ‘s/tcp, flag 10/–TCP ACK–/g’ | sed -e ‘s/tcp, flag 4 rst/–TCP RST–/g’ | sed -e ‘s/tcp, flag 14 rst/–TCP RST\/ACK–/g’ | sed -e ‘s/tcp, flag 18/–TCP PUSH\/ACK–/g’ | sed -e ‘s/tcp, flag 11 fin/–TCP FIN\/ACK–/g’ | sed -e ‘s/tcp, flag 5/–TCP FIN\/RST–/g’ | sed -e ‘s/icmp, (0\/0)/–ICMP Echo Reply–/g’ | sed -e ‘s/icmp, (8\/0)/–ICMP Echo Request–/g’ | sed -e ‘s/icmp, (3\/0)/–ICMP Destination Unreachable–/g’ | sed -e ‘s/icmp, (11\/0)/–ICMP Time Exceeded–/g’ | awk ‘/matched/ {print “\n\t\t\t=== PACKET START ===”}; {print};’

//Show Sessions
run show security flow session destination-prefix x.x.x.x

//Match Policy
run show security match-policies from-zone zonea to-zone zoneb source-ip x.x.x.x destination-ip x.x.x.x protocol tcp source-port 1024 destination-port xx

//Check for Block Group
show security policies from-zone untrust to-zone trust | display set | grep deny

//Find Syntax for an Existing Command
show | display set | xxxxxxxxx

//VPN Troubleshooting
show security ike security-associations [index ] [detail]
show security ipsec security-associations [index ] [detail]
show security ipsec statistics [index ]

//VPN
//Set proxy ID’s for a route based tunnel
set security ipsec vpn vpn-name ike proxy-identity local 10.0.0.0/8 remote 192.168.1.0/24 service any

//Packet Capture
set security datapath-debug capture-file my-capture
set security datapath-debug capture-file format pcap
set security datapath-debug capture-file size 1m
set security datapath-debug capture-file files 5
set security datapath-debug maximum-capture-size 400
set security datapath-debug action-profile do-capture event np-ingress packet-dump
set security datapath-debug packet-filter my-filter action-profile do-capture
set security datapath-debug packet-filter my-filter source-prefix 1.2.3.4/32

//Super SRX Packet Capture Filter
egrep ‘matched filter|(ge|fe|reth ) -.*- > .*|session found|Session \(id|session id|create|dst_nat|chose interface|dst_xlate|routed|search|denied|src_xlate|dip id|outgoing phy if|route to|DEST|post’ /var/log/mchtrace | uniq | sed -e ‘s/.*RT://g’ | awk ‘/matched/ {print “\n\t\t\t=== PACKET START ===”} ; {print} ;’ | awk ‘/^$/ {print “\t\t\t=== PACKET END ===”}; {print};’ ; echo | awk ‘/^$/ {print “\t\t\t=== PACKET END ===”}; {print};’

// Policy commands

show | display set (shows policy)
set system syslog
set security log
set interfaces ge-0/0/3 gigether-options auto-negotation (redundant-parent)
set security policies from-zone xxx to-zone xxx policy policy_name match
set security zones security-zone untrust address-book address
set security nat source rule-set zone-to-zone rule rule-source-nat match source-address 10.0.0.0
set routing-instances
set applications

set security ike proposal
set security ike policy
set security ike gateway
set security ipsec proposal
set security ipsec policy
set security ipsec vpn

show|compare
commit check
commit comments ticket#2222 and-quit

set security policies from-zone dmz to-zone trust policy 12 match source-address h_10.124.0.1 destination-address h_1.2.3.4 application tcp_22
set security policies from-zone dmz to-zone trust policy 12 then permit
set security policies from-zone dmz to-zone trust policy 12 then log session-init session-close

+         match {
+             source-address h_10.124.0.1;
+             destination-address h_1.2.3.4;
+             application tcp_22;
+         }
+         then {
+             permit;
+             log {
+                 session-init;
+                 session-close;
+             }
+         }
+     }

Various:

show system uptime	Uptime
show version	Version of platform (host/model)
show chassis firmware	Firmware loaded on FPCs
show system software detail
show chassis routing-engine	CPU, Memory for Routing-Engine
show chassis fan	Speed and status of fans
show chassis environment	Temperature status of components
show chassis hardware detail	Hardware inventory (backplane)
show system core-dumps	Core-dumps
show system alarms	System alarms
show chassis alarms	Alarms for hardware and chassis
show system boot-messages	Logs from boot sequence
show log chassisd	Logs for SRX chassis (Cards)
show log messages	Recent system messages
show configuration security log	Syslog configuration
show system buffers	Utilization of memory buffers
show system virtual-memory	Virtual memory utilization
show system processes	Processes running on system
show security idp memory	IDP memory statistics
show security monitoring performance session	Session counts on each FPC

Palo Alto Firewall Commands (4.0 – 5.0)

Palo Alto

// Base Help

lab@infostruction> ?
clear Clear runtime parameters
configure Manipulate software configuration information
debug Debug and diagnose
exit Exit this session
grep Searches file for lines containing a pattern match
less Examine debug file content
ping Ping hosts and networks
quit Exit this session
request Make system-level requests
scp Use ssh to copy file to another host
set Set operational parameters
show Show operational parameters
ssh Start a secure shell to another host
tail Print the last 10 lines of debug file content
username@hostname>

lab@infostruction# set ?
> deviceconfig deviceconfig
> mgt-config mgt-config
> network network configuration
> shared shared
> vsys vsys

// Device configuration and RMA
default login & password is admin/admin
scp import configuration 22 user@host:/path/to/file
set deviceconfig system hostname ip-address netmask default-gateway dns-setting server primary
set password

// Administration
check pending-changes **Check for uncommitted changes
show config
show config-locks
request commit-lock remove admin
save/load (saved config) -> set (candidate config) -> commit (active config)
edit, up, top **Change hierarchy

// Privilege Levels
superreader Has complete read-only access to the firewall.
vsysadmin Has full access to a selected virtual system on the firewall.
vsysreader Has read-only access to a selected virtual system on the firewall.
deviceadmin Has full access to a selected device, except for defining new accounts or virtual systems.
devicereader Has read-only access to a selected device.

// Health Commands
show counter global | match drop
show interface ethernetX/X
show system state filter * | match over **Packet overruns.
show session info **High concurrent sessions
show running resource-monitor **CPU (app-id, decoders, session setup teardown)
debug dataplane pool statistics **Work Queue and Segment reassembly.
show counter global filter aspect resource **Resource counters, TCP window information.
show system statistics **System Counters
show system info **Show system information
show network interface ethernet **Show Interface configuration
show arp
netstat all

// Failover – High Availability
request high-availability state suspend                     // Fail the master firewall and set to ineligible.
request high-availability state functional                    // Set current device to functional/eligible.
request high-availability sync-to-remote                  // Force config and session sync to peer
show high-availability state                        // Show current H/A status
show high-availability all                             // Show high-availability information on current device.
show high-availability link                            // Show H/A state of devices
show high-availability state-synchronisation         // View the sync state to the peer device
show high-availability control-link                     // Show H/A link statistics

// HA Upgrade Process
request high-availability state suspend – passive firewall
Upgrade passive to 4.1.7
request high-availability state suspend – Current old version active firewall
request high-availability state functional – Newly upgraded firewall (Outage until this command completes)
Upgrade old active firewall to 4.1.7
request high-availability state functional – Newly upgraded firewall

Notes:

HA processes can take up to 5 minutes to start up after reboot

// Troubleshooting
test nat-policy-match source destination protocol 6 destination-port
test security-policy-match source destination protocol 6 destination-port
test url **Provides URL category
show routing
show arp
show session

// Packet Capture
From the CLI:

Packet Filter

debug dataplane packet-diag set filter match source
debug dataplane packet-diag set filter match destination
debug dataplane packet-diag set filter on
debug dataplane packet-diag show setting

Packet Capture

debug dataplane packet-diag set capture stage drop file
debug dataplane packet-diag set capture stage transmit file
debug dataplane packet-diag set capture stage receive file
debug dataplane packet-diag set capture stage firewall file
debug dataplane packet-diag set capture on

Clear Packer Filter or capture

debug dataplane packet-diag set filter off
debug dataplane packet-diag set capture off
debug dataplane packet-diag clear filter all
debug dataplane packet-diag clear capture all

View PCAPs

view-pcap follow yes filter-pcap

Export the PCAPs

scp export filter-pcap from to
= user1@192.168.1.1:c:/1/scp
tftp export filter-pcap from to

// VPN Troubleshooting
show vpn flow  **View active tunnels
show vpn flow tunnel-id   **View additional information on tunnels based on ID
show vpn ike-sa
show vpn ipsec-sa
clear vpn ike-sa
clear vpn ipsec-sa
test vpn ike-sa gateway
test vpn ipsec-sa tunnel

// Debug Commands
debug authd
debug cli
debug dhcpd
debug high-availability agent
debug ike
debug log-collector
debug management-server
debug master-service
debug ssl-vpn
debug user-id