Troubleshoot Juniper Firewall/VPN devices
by Mats Hellman on Feb.04, 2009, under Juniper, Networking
Sometimes things don’t turn out the way you would expect and when they don’t you get to do the most rewarding thing in this business, troubleshoot. I love trouble because of the warm fuzzy feeling you get inside when you find out what’s causing the problem and solve it. And usually, when you set your mind to it you will solve the problem.
It’s like playing detective, like you used to do when you were a kid. For a few days now I’ve been looking at some network problems and had to rule out some firewalls. This very short article is something you can find in the documentation of your Juniper device or at Junipers website, http://www.juniper.net . So why am I writing about it? Well for some reason I find it easier to find my own writings than going trough a huge company website. It might be because of their large number of pages, articles, whitepapers etc. Anyway consider this something like a post-it for the few commands needed to do some debugging in a Juniper device.
The layout
To keep this fictional let’s say we have a network layout according to the following image.
So we have two sites connected via Juniper SSG’s over internet using VPN. I’m not going into setting up the VPN, maybe a article for the future, for now let’s assume they are connected and are showing that the connection is up and running.
How a Juniper device checks a packet
To understand the flow filters and debug output we first need to take a look at how a packet makes it’s way trough the firewall appliance. This is easy to see with a flowchart, so here it is. Click to get a larger image. As you can see there are quite a few checks before the package get’s sent out from the firewall. Let’s take a really fast look at the process.![]()
- Sanity check, first the packet goes trough a sanity check to make sure the packet’s not corrupt.
- Session exists, check if this is an previously started session, if it is then go to check the action from the policy settings.
- Check destination, where is the packet going?
- Destination reachable? If it’s not we drop or reject the packet. If the destination is reachable we check the policy to if it’s allowed.
- Policy ok? If the packet’s not allowed we drop/reject the package. It it’s ok according to policy we move on.
- Arp query, we need to do a ARP Query to find out our way to the destination.
- Perform action according to policy, this is self explanatory.
- Add to session table, without this we couldn’t check if session exists.
So now that we know how the traffic move trough the firewall we can start looking at what’s happening when it does.
The Case
Let’s say we have a server in one of our subnet’s and the local systems administrator has problems whit it accessing the offsite DNS server. The DNS server is located in the other site. So to check if DNS traffic is going trough the VPN tunnel. If you have NSM you can do the same with it but this time I’m going to use plain old SSH access to the firewall. After you enter the prompt set up a filter to see the traffic.
set ffilter src-ip 192.168.2.250 dst-ip 192.168.1.251 dst-port 53
The command above sets flow filter to follow traffic coming from 192.168.2.250 and going to 192.168.1.251, and the destination port should be 53.
Now let’s turn on the debugging.
clear db <- clear the debug database so nothing old get’s in the way.
get db str
****** 23799281.0: <Trust/ethernet0/0> packet received [176]******
ipid = 17087(42bf), @04e492e4
packet passed sanity check.
ethernet0/0:192.168.1.251/53->192.168.2.250/49788,17<Root>
existing session found. sess token 4
flow got session.
flow session id 46122
existing vector list 285-369a1d4.
post addr xlation: 192.168.1.251->192.168.2.250.
update policy out counter info.
skipping pre-frag
going into tunnel 400000b6.
flow_encrypt: pipeline.
chip info: PIO. Tunnel id 000000b6
(vn2) doing ESP encryption and size =184
ipsec encrypt prepare engine done
ipsec encrypt set engine done
ipsec auth done
ipsec encrypt engine released
ipsec encrypt done
put packet(5388fd0) into flush queue.
remove packet(5388fd0) out from flush queue.
So what do we see here. First we see the packet passing sanity check.
packet passed sanity check.
The next line tells us that the local DNS server is indeed answering the DNS requests.
ethernet0/0:192.168.1.251/53->192.168.2.250/49788,17<Root>
The SSG also finds an existing session so the packet is handled according to the policies. No problems here so we can now go to do the same thing at the other end or start troubleshooting the DNS client offsite.
Turning of the debug
To clear the settings we type the following.
undebug all
unset ffilter
clear db
After that log out and you´re done.
Finishing words
As I said in the beginning this is a very short informational post. Nothing fancy. Just the basics. Hope you got as much out of it reading it as I got writing it.
No related posts.
June 29th, 2009 on 10:05
Good Blog…Valuable Information. Thanx
July 9th, 2009 on 15:56
Glad you like it.
Mats
November 14th, 2009 on 08:58
Really Informational
November 14th, 2009 on 11:53
Glad you like it