Using ping simulation to troubleshoot Rules and Routes(10.x)

Security Gateway Articles and How to's
Locked
jono
Posts: 85
Joined: 18 Apr 2008, 10:46
Location: Clavister HQ - Örnsköldsvik

Using ping simulation to troubleshoot Rules and Routes(10.x)

Post by jono » 23 Apr 2008, 14:13

This article applies to:
  • Clavister CorePlus 8.x, 9.x
  • Clavister cOS Core 10.x
Problem

There is a network problem that we are unable to determine the cause of. We are not sure if it is IP Rules, a routing issue or something else.

Description

A very useful tool when trying to find a problem with a rule or route is a so called "ping simulation". It injects a ping packet on a interface with a faked sender address, to a desired destination address. It will simulate a packet entering the Clavister on one interface, passing through the Clavister and exiting on the interface decided by the routing table. The route chosen and the IP rules consulted for this traffic can be printed out as part of the simulation, so you will see exactly what is going on.

These examples are performed in the CLI of the Clavister Security Gateway, and it can be accessed in a variety of ways, such as via SSH, serial console or the centralized management software.

Syntax
  • Text in brackets and <italics> is chosen by the user.
    ping <dest_ip> -srcif=<source_interface> -srcip=<source_ip> -verbose
    Type help ping in the console for a detailed explanation of the syntax.
Scenario
  • 192.168.200.0/24 is the private internal network.
  • 1.2.3.2 is the external IP of the Clavister Security Gateway.
  • 1.2.3.1 is the external gateway of the Clavister Security Gateway.
  • We have a rule allowing ping traffic:
Using ping simulation to troubleshoot Rules and Routes.jpg
Using ping simulation to troubleshoot Rules and Routes.jpg (19.24 KiB) Viewed 7649 times
Successful example
  • Cmd> ping 192.36.125.18 -srcif=lan -srcip=192.168.200.50 -verbose
This will send a ping packet (ICMP):
  • To the host 192.36.125.18, located at Sunet (the Swedish University Network)
  • injected on the lan interface
  • addressed from 192.168.200.50
  • with verbose results
Since the 192.168.200.50 is routed on the lan interface, this will be successful and the output will look like this:
  • Cmd> ping 192.36.125.18 -srcif=lan -srcip=192.168.200.50 -verbose
    Rule and routing information for ping:
    allowed by rule "Nat_ping"
    sent via route "0.0.0.0/0 via wan, gw 1.2.3.1" in PBR table "main"
    Sending 1 4-byte ping to 192.36.125.18 from 1.2.3.2.
    Reply from 192.36.125.18  seq=0  time= 20 ms  TTL=54
    Ping Results:  Sent: 1, Received:1, Loss: 0%, Avg RTT: 20.0 ms



You will see both what rule triggered on the traffic and what route the traffic will follow. This can be of great help when troubleshooting.

Unsuccessful example

If we change the <src_ip> to an IP not routed on the lan interface:
  • Cmd> ping 192.36.125.18 -srcif=lan -srcip=192.168.100.50 -v
    Rule and routing information for ping:
    DROPPED by rule "Default_Access_Rule"
The traffic is dropped by the Default_Access_Rule, which means that the source network isn't routed on the lan interface, which is correct in this case as we have 192.168.200.0/24 on the lan interface.
This is also known as ingress routing, where we check that the incoming packet's source address is valid on that interface.

We have concluded that it is a routing problem we need to look into.

Other uses
This technique can also be used to troubleshoot Lan-to-Lan VPN tunnels.

Note 1: Since version CorePlus 8.90 you can use ping simulation with different TCP/UDP ports in addition to ICMP.
Note 2: The simulation will fail if it goes through any Application layer gateways.
Note 3: Even though the syntax is slightly different in version 9.xx the basic principle is still the same.
Note 4: Since version cOS Core 10.11, the "recvif" was renamed to "srcif" in order to be in sync with what it's called everywhere else.

Locked