Dr Ahriakin's Singalong JNCIE-Sec Blog

mtucker502 wrote: »

Interopability with 3rd party devices -- I can only expect custom proposals, manual NHTB, OSPF over GRE over IPSEC. Think that is correct?

Ok, my last thread jack of random hints for the night...

One of the larger issues with inter-op would be NHTB and routing. So dealing with NHTB in Juniper-Juniper and Random-Other-Vendor scenarios would be a good skill. Custom proposals could be an issue, but those are pretty easy to configure. Hmmm, I guess looking at inter-op, could you bring up a VPN tunnel if you didn't explicitly know all the parameters and configurations used by the remote end point?

Some good points there Zoidberg, I think people would be wise to listen to your advice.

One thing that I found interesting as I was reading through the Junos Security book is the tcp-rst knob found under zone configuration. I've seen that knob before but never gave it a second thought. Then it occurred to me, somebody, who was evil, could use the tcp-rst knob as a task question in the exam, and man, I wouldn't be surprised if everybody missed it.

Moral of the story, it's important to know all the small, even rarely used, knobs.

Zoidberg, thank you for the words of wisdom. It is funny that it never occurred to me that DRP could mean dynamic routing protocols. I figure RIB groups will be required for policy based routing but was hoping I wouldn't see any IS-IS or BGP on the exam!

Good point too Aldur. Things like this are what made me skeptical of "advanced security policy options". I know all the options from memory but I was worried I was missing something more..."advanced". I think they're referring to anything beyond permit/deny.

During my studies I've spent some time trying to figure out why my config will not work in certain scenarios. Here are some to hopefully save others time:

Can’t terminate VPN in a routing instance
Cannot terminate VPN on lo0 interface on high end SRXs
Hidden command “local-address” can be used for loopback with multiple addresses (since only one loopback per routing instance)

I take the exam on 8/23 and I think I finally have everything down. Now time to increase my speed.

yeah, no IKE in a routing instance, but keep in mind that has changed as of 11.4, not that it matters for the exam since it only goes up to 11.1. The local address command is useful, but I would think that they would not put something on the exam that would require you to use a hidden command.

And I would highly recommend including OSPF, IS-IS, RIP, and BGP in your studies with DRP through IPsec. Those are all valid topics. Would really suck to get to the exam and get IS-IS or BGP through an IPsec tunnel if you've never practiced them yourself.

ohh 8/23, that soon, where you flying out to for the exam? I'll be taking my exam towards the end of Aug maybe the beginning of Sept, depending how things go. I do have the advantage of being inside of Juniper Educational Services, so access to all the needed training materials

I'm flying out of Orlando, taking it in Herndon. Lucky you! I had to buy all of the coursewares from Onfulfillment.com. I read through those back in May when I took the written exams. I started a crash course study program last weekend and plan to try and read through some of Junos Routing O'Reilly book too. I did the first lab in the Inet Zero and it was fairly straightforward. Had to look in the appendix for 2 tasks. I'm going to try for the super lab next weekend to see how I'm doing by then. If I'm still lacking, I may take a few days off the week prior to the exam for some extra practice.

This will be the first expert level exam I've taken. Read on Stefan's blog I think that you should leave 2 days prior just in case there are any issues. I'll be up there on Tuesday and leaving Friday.

After JNCIE-SEC, JNCIE-ENT here I come! I'm shooting to have that one done by January

Don't forget to review all the fun knobs hiding in the security flow hierarchy.

I've mainly been reading up on Firewall Filters, using the "Junos Policy Framework and Configuration guide" for more detail and some more NAT64 since I need that for work. I finally got full (all v6 Pool to all v4 internet) xlation working and turned up some DNS64 capable servers this morning but haven't been able to do proper end to end testing beyond simple pings. But since they are working I at least know the config itself is fine. Here's an example.

source {
rule-set Lab-V6_NAT64 {
from zone Lab-V6;
to zone OUTSIDE;
rule 1 {
match {
source-address 0::/0;
destination-address 0.0.0.0/0;
}
then {
source-nat {
interface;
}
}
}
}
}
destination {
pool Public-1 {
address 0.0.0.0/0;
}
rule-set NAT64-DST-1 {
from zone Lab-V6;
rule NAT64-STD {
match {
source-address 0::/0;
destination-address 64:ff9b::/96;
}
then {
destination-nat pool Public-1;
}
}
}
}

@mtucker

Wow man, that's a serious study schedule you got there. Here's hoping you pass your JNCIE-SEC on the 23rd so you can jump right to the ENT studies.

Definitely report back with how it goes, I just found out that I have mine scheduled for 9/4, so there's a good chance our JNCIE-SEC numbers will be back to back

@Ahriakin

Very interesting on the nat64 stuff, that's definitely something I need to learn better.

Lately I've been working on my speed and strategy of attacking the exam. From the exam blue print we know that chassis clustering and transparent mode are involved. And both topics require you to reboot the firewall/routers. So I've decided that any srx that is in a cluster, or any that needs to be in transparent mode, will be done that way from the start of the exam, and while they are rebooting, I'll be hitting other tasks. Also, doing a commit in a chassis cluster takes much longer than a typical commit on a stand alone srx. For that reason I'm trying to configure as much as possible in a cluster, and do as few as commits as possible. And while the commit is running, I'll be working on other tasks in the lab.

I'm really hoping, come test day, to have the entire exam done before lunch time, so that way I'll have at least 4 hrs to verify everything.

random time tips...

test out idp configs and see how much that impacts commit times. it's been awhile since i've tried that on branch devices, but i think i remember it became annoying, especially if you keep needing to do a number commits to change flow debugs and tweak configs. if it is a commit bottleneck, it might be worth configuring later or leaving some options deactivated until you have most everything working. of course, on the flip side, you could get everything working and then you configure idp and break everything

so read ahead and plan things out to work best for you.

if you need to use the idp template commit script, make sure you remove it after the first commit. otherwise you will be wasting a lot of time watching the box think every time you commit.

if you're confident in your work and configuration and troubleshooting, but something is just not working and you think it is the lab environment, point it out to the proctor. a friend recently lost well over an hour because of a lab glitch.

@Aldur

We have the same goals for finish time. I plan to finish by lunchtime to have all afternoon to verify verify verify!
Good call on cluster commits (it does take a long time).

@zoidberg
Your memory is correct. Enabling IDP can make commits take 2-3 minutes on a SRX100.
I sure hope I do not experience any lab glitches. Every "issue" I've run into so far in my studies has ended up being an unsupported feature. My most recent was me trying to understand why Dynamic-VPNs cannot have traffic initiated from the SRX side, only from the Dynamic client side. I thought I had a configuration problem.

Back going through the JunOS Security Book IPS/IDP chapters. I had completely forgotten about the modes, it doesn't help they're buried off under [security forwarding-process] . Coming from a Cisco and TippingPoint background primarily on the IPS side it's taken a while for the policy structure to 'click' with me. I'm so used to arrange per-signature or per-category response actions whereas with JunOS you really order your Policies for respons-action, then include the components/objects. It's more like a firewall/ACL mindset imho but I guess it can have some advantages in deciding on priorities and orders for processing. Initially I didn't see much point in having a flow definition inside the IPS policies (since you inspect based on security policies that in themselves include that information) but i see now i can do similar things that I used virtual-segments for on the TippingPoints - Essentially make exceptions based on network details and treat the flow context in the security policy really as a superset. I think playing with this will be my focus for the next week or 2. We're testing using JunoSpace for the IPS policy management, tbh we didn't really like NSM and hated that once we started using it we pretty much had to leave the CLI alone or risk Sync issues, Space doesn't have this limitation but there are some others (like not being able to re-order or copy rules within a policy from what I can see, easy to do from the CLI though).

I'm having a weird issue with OSPF over GRE over Policy Based IPSec VPN. Using Route Based VPNs is no issue.

Both the loopback and the GRE interfaces are in the untrust zone.

I configured my GRE tunnels to use the loopbacks as source/destination. I then configured my policy (untrust to untrust) to tunnel any traffic between the loopbacks. This should force the GRE tunnel to use the IPSec VPN but it isn't.

If I deactivate the policy and add a static route for the loopback addresses the GRE tunnel comes up and OSPF forms adjacencies.

Someone please please please post a working config if you have one. Searching the forums just ends with everyone settling on route based vpn after not getting policy based vpn to work.

I spent a good amount of time today trying to figure out why I couldn't get GRE over a Policy Based VPN to work. I ended up finding this KB article: KB19372 (Juniper Networks - [SRX] GRE over IPSEC Configuration Example - Knowledge Base).

I confirmed with JTAC that this still applies and it is not possible to have GRE over Policy Based VPN.

So the big question is....why does INETZERO's JNCIE-SEC workbook have this as a task?

Are they completely mad?
Is this a trick question indicating that the actual JNCIE-SEC exam will have tasks that are not possible to complete? (this is not something I have considered)
Or are JTAC and the KB wrong and GRE over Policy Based VPN is actually possible?

-A very, very irritated lab rat.

I have to agree with JTAC and say it's not supported... unless it's been a recent new feature addition. I don't watch new VPN features closely, but I doubt it's been added. If you consider the life of a packet with the SRX, locally generated traffic is not policy evaluated, only traffic coming into SRX is. So if you're not doing a policy lookup on the GRE traffic, how can you send it across a policy VPN? At least that's the way I see it. I believe that would be the same for branch and high-end, but my bias is towards high-end, so my apologies if branch behaves differently here.

You are correct. I spoke with Jorg and he informed me they will be revising their workbook and sending out an updated version with corrected tasks.

I'll be honest I'm not sure why they sent out a workbook that had impossible tasks to begin with. It definitely had me worried about the exam. Jorg was fast to answer my emails though even on a weekend which was very much appreciated.

Actually, as bad as it seems, that's not unique. The CCIE side is much more mature yet you'd be amazed at the amount of errors the workbooks of even the top vendors in that field have. Budgets are tight I guess, and i think more time is spent on direct customer training than these downloadable assets.

Thanks for getting my hopes up

Once I'm done reviewing the entire workbook I'll post my errors here so that others can learn from my wasted time

I'm also sending INETZERO a copy of the errors so they can fix their workbook.

Oh, and here is a list of a little "gotchas" that I've found during my last month of study:

=========================================================
syslog levels and facilities
ntp (to "ensure" that a device syncs it's time you need to use "boot-server <server>"
set feature-profile anti-virus kaspersky-lab-engine profile kasp-av scan-options scan-mode all
persistent NAT (source nat) requires port translation to be disabled (set security nat source interface port-overloading off)
av timeouts are in seconds

NAT***********
source nat match filters are done on subnets (or /32 hosts) not ranges. You may have to break up ranges into subnets/hosts for the match rule
custom-object protocol commands are lower case
Apparently having a NAT rule may mean that you need to have security policies to allow the traffic
Destination NAT - for VIP like functionality the pool must specify the PORT

Loopback's security zone requires any/any/any/permit intra zone rule

SCREEN********
syn-flood-protection is under [security flow syn-flood-protection]
syn flood alarm threshold is threshold-attack threshold (if attack thressheld is 500 and you want an alarm at 2000 pps then it's 2000-500)

anti-spam - don't forget to set the spam-action (setting the cust-tag string doesn't cut it!!!!)

======================================================

Some of these may only make sense to me. Hopefully not. Most of these seem obvious to me, but during my first week of study, they definitely were the "tedious" things I had to remember.

Woohoo, we now have Native and NAT64'd/DNS64'd traffic working over v6. to the internet..not that it matters a lot for the exam side of this thread but it's a milestone for myself. It turned out to be easier than I had thought, we were all a little surprised when it just...er...worked...:). Still trying to wrap my head around summarizing v6 correctly, it made me feel better that one of our RS guys was having the same brain-farts and moving the mask values the wrong direction etc. Like I mentioned earlier it's easy to fall into the trap of approaching it all as brand new and bypassing some of those mental ASICs we've built over the years for v4, making silly beginner mistakes all over again.

I'm finished. Let the waiting begin!

Fingers crossed...

Roguetadhg

We're wishing the best, definitely!

@ mtucker

Any word yet?

Back from vacation and I need to do some re-shuffling of my schedule. I had planned on getting a JNCIE-Sec bootcamp in and doing the lab before Xmas this year, then re-certifying my CCIE at the start of January. But since Cisco are changing to Blueprint 4.0 in November I really need to switch gears or face a much longer study period for that one (which means extending my overall timelines). Also the Bootcamp still hasn't materialized so I've decided to use my week of training this year doing the CEH, more distractions

(though I am looking forward to the course). Anyway, it means no JNCIE-Sec heavy study for a while, a month or so at the very least. We're still doing some new SRX projects at work so I may add some updates for anything I pick up along the way that may be relevant here but that'll probably be it, Cisco has to come first this year. Now the bigger question is if I can still make it all before end of year...

CEH course finished and my CCIE renewal is booked for the end of this month so still no dedicated/clear time to get back to this but as I mentioned I will post what I think is generally useful info. I happen across.

I ran into issues testing NAT64 after switching some lab equipment from 10.4 to 11.4. The config I posted previously used a source and destination-nat pairing which worked fine under 10.4, it then broke under 11.4, you have to replace the destination-nat with static-nat instead, the source-nat remains the same. The destination-nat config under 11.4 does not show any errors, it simply does not come into effect. The key is setting the static-nat target as the special "inet" address.

10.4: OLD

[edit security nat destination]

pool Public-1 {
address 0.0.0.0/0;
}
#
rule-set NAT64-Test-Servers {
from zone IPv6-Test-LAN;
rule NAT64-INTERNET {
match {
destination-address 64:ff9b::/96;
}
then {
destination-nat pool Public-1;
}
}
}

11.4 : NEW

[edit security nat static]

rule-set NAT64-Test-Servers-STATIC {
from zone IPv6-Test-LAN;
rule NAT64-Test-Servers-INET-STATIC {
match {
destination-address 64:ff9b::/96;
}
then {
static-nat {
inet;
}
}
}
}

roomi

this is a very good platform for those who want to be JNCIE-Sec. i just want to ask you guys about the topology you followed for this lab exam.

mharoonafzal

How can I get the JNCIE-SEC lab-book??

You can buy it from iNetZero at JNCIE studyguides workbooks exam rack rental

Well still trying to knock out the CCIE recert, which fingers crossed will be this friday. In the meantime another nice nugget relating to IPv6, and IDP. Using NAT64 with IDP enabled will core-**** the SRX, apparently it can't sort the wings correctly between protocols for DPI. We have an "Enhancement Request" in to fix what is really a bug so we'll see how that goes, but beware...

K...CCIE written down again for another 2 years. Back to Juniper it is...after a week's rest