Knowledge Search


×
 

[Archive] What Are Some Additional VPN Troubleshooting Steps?

  [KB4403] Show Article Properties


Summary:

What Are Some Additional VPN Troubleshooting Steps?

Symptoms:


 

Solution:

To further troubleshoot the VPN connection, you can perform the debug flow basic procedure. The following are interfaces to be familiar with when performing debug flow basic on the NetScreen firewall:

  • Ingress Interface: incoming interface from which a packet enters the NetScreen firewall
  • Egress Interface: exiting interface once a packet has been processed and sent to its destination

The NetScreen can only catch the debug flow for packets incoming on the ingress interface. If you ping from the NetScreen to the ISP's DNS server, the outgoing packet would not be caught by the debug flow as it is considered an outgoing packet on the egress interface. Only the incoming return packet would be caught. Though if there were a problem with layer 2 (ARP), the NetScreen would not send the packet out at all, would not receive a reply, and nothing would be caught in the debug buffer. The best practice is to ping the DNS server or any IP on the Internet that you know is live from a host on the trusted side of the network.

noteIn this example we will run a ping from 192.168.1.10 to 210.1.1.10.

To debug flow basic on the firewall, perform the following steps:

Open the Command Line Interface (CLI). For more information on how to open the CLI, go to Accessing the Command Line Interface Using Telnet.

Step twoEnter     set ff dst-ip 210.1.1.10    press ENTER.

Step threeEnter     get ff    press ENTER.

Step fourEnter   debug basic     press ENTER.

Step fiveEnter    clear db    press ENTER.

noteBelow is an example of the commands:

Image of example
 

Step sixFrom the CLI, enter    ping 210.1.1.10    press ENTER.

noteIf the ISP was up and working correctly, you would receive the following reply caught in the debug buffer after the ICMP request is sent out:

ns208-> get db stream  
****** 12553.0: packet received [60]****** Packet arrived on the eth1 interface
ipid = 29503(733f), @d7806910  
packet passed sanity check. IP id
ethernet1:192.168.1.10/1280->210.1.1.10/512,1(8/0) Src IP, Port, Dst IP, port incl Protocol 1
chose interface ethernet1 as incoming nat if. Int eth1 is placed in NAT mode
search route to (192.168.1.10->210.1.1.10) in vr trust-vr for vsd-0/flag-0/ifp-null Route lookup in trust-vr
route 210.1.1.10->1.1.1.2, to ethernet3 route found to gateway 1.1.1.2 exiting interface int eth3
routed (210.1.1.10, 0.0.0.0) from ethernet1 (ethernet1 in 0) to ethernet3 packet routed
policy search from zone 2-> zone 1 Policy lookup performed from Trust (2) to Untrust (1)
Permitted by policy 3 matched policy ID 3
choose interface ethernet3 as outgoing phy if choose physical interface eth3
no loop on ifp ethernet3.  
session application type 0, name None, timeout 60sec session time created as 60 seconds for ICMP
service lookup identified service 0. service lookup performed
existing vector list 1-559ef00.  
Session (id:76) created for first pak 1 Create session with ID 76
route to 1.1.1.2 Routed packet to 1.1.1.2
arp entry found for 1.1.1.2 Already had ARP entry for 1.1.1.2
nsp2 wing prepared, ready  
cache mac in the session Cached MAC address in the session
flow got session.  
flow session id 76  
post addr xlation: 1.1.1.1->210.1.1.10. Translate src address to egress interface IP
packet send out to 0010db103041 through ethernet3 Packet sent out on the wire

note” If the ISP was up and working correctly, you would receive the following reply caught in the debug buffer after the ICMP request is sent out.

****** 14466.0: packet received [60]****** Reply caught on int eth3
ipid = 1239(04d7), @d785d110  
packet passed sanity check.  
ethernet3:210.1.1.10/512->1.1.1.1/1036,1(0/0) Src IP, port, Dst IP, port and protocol 1
existing session found. sess token 3  
flow got session.  
flow session id 98 Matched outgoing session already created
post addr xlation: 210.1.1.10->192.168.1.10.  
packet send out to 000bdb022203 (cached) through ethernet1 Packet sent back to 192.168.1.10

Another possibility why no reply is received is that the outgoing packet's IP address is not being source translated (NAT). This means that the NetScreen will send the packet out if it matches a policy, but the private IP range that you are using will be the real source IP. If this packet is not dropped before it reaches the ISP, the ISP will route the reply back to you in the 192.168.0.0/16 range as a non-routable IP. For more information on NAT and private IP addresses, go to What is Network Address Translation (NAT)?

This is normally because of two factors:

  • If the Trusted interface, or in the case of the NS-208, the eth1 interface is in NAT mode, then you will not have to specify NAT in the advanced properties of the policy.
  • If the Trusted interface, or in the case of the NS-208, the eth1 interface is in route mode, then you must have a policy that has NAT (Source Address Translation) enabled.
ns208-> get interface eth1
Interface ethernet1:
number 0, if_info 0, if_index 0, mode nat
link up, phy-link up/half-duplex
vsys Root, zone Trust, vr trust-vr
dhcp client disabled
PPPoE disabled
*ip 192.168.1.1/24 mac 0010.db19.a7d0
*manage ip 192.168.1.1, mac 0010.db19.a7d0
route-deny disable
ping enabled, telnet enabled, SSH enabled, SNMP enabled
web enabled, ident-reset disabled, SSL enabled
webauth disabled, webauth-ip 0.0.0.0
OSPF disabled BGP disabled RIP disabled
bandwidth: physical 100000kbps, configured 0kbps, current 0kbps
total configured gbw 0kbps, total allocated gbw 0kbps
DHCP-Relay disabled
DHCP-server disabled

 

Be very careful when using flow filters. If you have only set a flow filter defining the src-ip and dst- ip, then you would never catch the reply, as the NetScreen will only catch packets for the request going out from 192.168.1.10 to 210.1.1.10. It would not catch the return reply packet from 210.1.1.10 to 192.168.1.10.

A best practice on heavily utilized networks is to specify two flow filter entries. One for the src-ip and dst-ip for the outgoing packet, and one flow filter entry for the reply from the src-ip of the actual original destination only. Or you could specify the src-ip to the NAT IP that was used on the outgoing packet.

The reason for this is that if you are performing NAT on the outgoing packet, then the return packet will not actually be the original source IP (192.168.1.10), but in fact the egress interface IP or an IP from the DIP pool.



 

Related Links: