Dr Ahriakin's Singalong JNCIE-Sec Blog
Comments
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Conditional Router Advertisement worked like a charm...in one direction. I can withdraw and re-advertise the LAN routes in sync with it's RETH failover across the each Node's WAN links but I haven't found a way yet to pull or re-prioritize the peers advertisement to the SRX at the same time, so it can still be asymmetric. The problem is the process has to track a RETH, so with 2 standalones on the WAN side I can't do the same in reverse. I tried tricking the system by making both WAN links the only interfaces in 2 new RETHs but that has it's own issues when it comes to actual failover. Anyway I'll have to think over this during the day and maybe take one more stab at it tonight before giving up.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Frustrating night. During the day I decided to give up on the routing side, traffic will have to possibly be asymmetric. So I went to test Inter-VRF NAT as described in many examples....and it doesn't work. Every piece of documentation I could find describes using a Static-NAT set with "from instance". The NAT itself works, the problem is that since it's a Static NAT it takes place before the route-lookup, so when it gets to that stage it's still looking on the Ingress VRF and just loops back into the ingress network. I checked the logs from a flow trace and verified this behaviour. I spent a lot of time troubleshooting that part and got nowhere. So I took a different approach and configured opposing Source and Destination-NAT pairs for the overlapped addresses, I just made sure to set the Destination-NAT pools in the opposing VRF rather than the ingress in some blind attempt to force some sort of logical slingshot across their tables. And it worked. I've copied out my configs and some traces to look over tomorrow when I have time, I'm still not 100% that I did the InterVrf 100% right, or that I'm doing this correctly. Tired as hell at the moment so it'll have to wait.
EDIT: If anyone has gotten inter-vrf NAT working for overlapped space PLEASE chime in
We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
In case you're interested here are some of the details. I'm using the RFC6598 range of 100.64.0.0/10 for the NAT range on both sides (/11 per side).
Inter-VRF Static NAT
Routes on both sides are pretty similar (in particular both have 10.30.30.0/24 with different hops).[edit security nat static] rule-set ACME-NAT { from routing-instance LAN; rule DOUBLE-NAT-ACME { match { destination-address 100.96.30.30/32; } then { static-nat { prefix { 10.30.30.30/32; } } } } } rule-set LAN-NAT { from routing-instance ACME; rule DOUBLE-NAT-LAN { match { destination-address 100.64.10.202/32; } then { static-nat { prefix { 10.10.10.202/32; } } } } } } }
Failure Flow TraceJan 15 21:30:05 21:30:05.520366:CID-1:RT:flow_initiate_first_path: first pak no session Jan 15 21:30:05 21:30:05.520366:CID-1:RT: flow find session returns error. Jan 15 21:30:05 21:30:05.520366:CID-1:RT: ----- flow_process_pkt rc 0x7 (fp rc -1) Jan 15 21:30:06 21:30:06.536392:CID-1:RT:<10.10.10.202/250->100.96.30.30/2793;1> matched filter ICMP: Jan 15 21:30:06 21:30:06.536392:CID-1:RT:packet [84] ipid = 51601, @4091a31a Jan 15 21:30:06 21:30:06.536392:CID-1:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 14, common flag 0x0, mbuf 0x4091a100, rtbl_idx = 5 Jan 15 21:30:06 21:30:06.536392:CID-1:RT: flow process pak fast ifl 69 in_ifp fe-0/0/0.0 [I][B]## Initial connection[/B][/I] [B]Jan 15 21:30:06 21:30:06.536392:CID-1:RT: fe-0/0/0.0:10.10.10.202->100.96.30.30, icmp, (8/0)[/B] Jan 15 21:30:06 21:30:06.536392:CID-1:RT: find flow: table 0x42687228, hash 15454(0xffff), sa 10.10.10.202, da 100.96.30.30, sp 250, dp 2793, proto 1, tok 20486 Jan 15 21:30:06 21:30:06.536392:CID-1:RT: no session found, start first path. in_tunnel - 0, from_cp_flag - 0 Jan 15 21:30:06 21:30:06.536392:CID-1:RT: flow_first_create_session Jan 15 21:30:06 21:30:06.536392:CID-1:RT:Installing pending sess (75[IMG]https://us.v-cdn.net/6030959/uploads/images/smilies/icon_cool.gif[/IMG] in ager Jan 15 21:30:06 21:30:06.536392:CID-1:RT:First path alloc and instl pending session, natp=0x44768170, id=758 Jan 15 21:30:06 21:30:06.536392:CID-1:RT: flow_first_in_dst_nat: in <fe-0/0/0.0>, out <N/A> dst_adr 100.96.30.30, sp 250, dp 2793 Jan 15 21:30:06 21:30:06.536392:CID-1:RT: chose interface fe-0/0/0.0 as incoming nat if. [I][B]## Static happens as expected[/B][/I], [B][I]100.96.30.30 xlated to 10.30.30.30[/I][/B] [B]Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_first_rule_dst_xlate: packet 10.10.10.202->100.96.30.30 nsp2 0.0.0.0->10.30.30.30.[/B] Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_first_routing: vr_id 5, call flow_route_lookup(): src_ip 10.10.10.202, x_dst_ip 10.30.30.30, in ifp fe-0/0/0.0, out ifp N/A sp 250, dp 2793, ip_proto 1, tos 0 Jan 15 21:30:06 21:30:06.536392:CID-1:RT:Doing DESTINATION addr route-lookup Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_rt_lkup in VR-id: 5 Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_rt_lkup: Found route entry 0x0x45bc02e0,nh id 0x264, out if 0x47 Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_rt_lkup: nh word 0x2640011 Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_ipv4_rt_lkup success 10.30.30.30, iifl 0x45, oifl 0x47 [B][I]## Route-lookup happens on Ingress VRF, tries to push the connection back out the same Zone[/I] Jan 15 21:30:06 21:30:06.536392:CID-1:RT: routed (x_dst_ip 10.30.30.30) from LAN (fe-0/0/0.0 in 0) to fe-1/0/0.0, Next-hop: 10.10.15.20[/B] [B]Jan 15 21:30:06 21:30:06.536392:CID-1:RT:flow_first_policy_search: policy search from zone LAN-> zone LAN (0x114,0xfa0ae9,0xae9)[/B] Jan 15 21:30:06 21:30:06.536392:CID-1:RT: app 0, timeout 60s, curr ageout 60s Jan 15 21:30:06 21:30:06.536392:CID-1:RT: packet dropped, denied by policy Jan 15 21:30:06 21:30:06.536392:CID-1:RT: denied by policy default-policy-00(2), dropping pkt Jan 15 21:30:06 21:30:06.536392:CID-1:RT: packet dropped, policy deny. Jan 15 21:30:06 21:30:06.536392:CID-1:RT:set_nat_invalid: natp:id 758, flag 3c5f
We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
zoidberg
Member Posts: 365 ■■■■□□□□□□
Not sure if this is quite the inter-vr nat you are looking for... but I've done something similar.
Traffic comes in VR-A, gets filter based forwarded to VR-B. Nat rule matches from zone VR-A-zone to zone VR-B-zone. VR-B has it's route to send traffic out it's egress interface. And return traffic into VR-B has routes direct traffic to next-table VR-A.inet.0.
A weird oddity/bug in 10.x caused a problem that sounds similar to what you are describing. The route lookup done during sessions establishment was actually being done in inet.0, not in VR-B.inet.0 like you would expect, and not even in VR-A.inet.0 where the traffic ingressed. So, as a workaround, I believe I needed to install a matching route in inet.0 saying next-table VR-B.inet.0 (I think that's how I did it). I thought this bug was fixed somewhere in 10.4 however, and I'm pretty sure you're using a 11.1 or 11.4. -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
And the Source+destination NAT pairs that appear to work.
From LAN Source to ACME Host
Session ID: 6087, Policy name: Permit-ANY/4, State: Forward, Timeout: 2, Valid
In: 10.10.10.202/1 --> 100.96.30.30/3109;icmp, If: fe-0/0/0.0, Pkts: 1, Bytes: 84
Out: 100.96.30.30/3109 --> 10.10.10.202/1;icmp, If: fe-1/0/1.0, Pkts: 0, Bytes: 0
FROM ACME Source to LAN Host
Session ID: 3203, Policy name: Permit-ANY/5, State: Active, Timeout: 2, Valid
In: 10.30.30.30/5621 --> 100.64.10.202/6812;icmp, If: fe-1/0/1.0, Pkts: 0, Bytes: 0
Out: 10.10.10.202/6812 --> 100.96.30.30/47572;icmp, If: fe-0/0/0.0, Pkts: 1, Bytes: 100[edit security nat] nat { source { pool ACME-NAT { routing-instance { LAN; } address { 100.96.30.30/32; } port inactive: no-translation; } pool LAN-NAT { routing-instance { ACME; } address { 100.64.10.202/32; } port inactive: no-translation; } rule-set SOURCE-ACME-LAN { from zone ACME; to zone LAN; rule SNAT-1 { match { source-address 10.30.30.30/32; } then { source-nat { pool { ACME-NAT; } } } } } rule-set SOURCE-LAN-ACME { from zone LAN; to zone ACME; rule SNAT-2 { match { source-address 10.10.10.202/32; } then { source-nat { pool { LAN-NAT; } } } } } } destination { pool LAN { routing-instance { LAN; } address 10.10.10.202/32; } pool ACME { routing-instance { ACME; } address 10.30.30.30/32; } rule-set DEST-NAT-ACME { from zone LAN; rule DEST-NAT-ACME-LAN { match { destination-address 100.96.30.30/32; } then { destination-nat pool ACME; } } } rule-set DEST-NAT-LAN { from zone ACME; rule DEST-NAT-LAN-ACME { match { destination-address 100.64.10.202/11; } then { destination-nat pool LAN; } } } }
Flow Trace (edited for brevity)Jan 15 22:21:50 22:21:52.293174:CID-2:RT: fe-0/0/0.0:10.10.10.202->100.96.30.30, icmp, (8/0) Jan 15 22:21:50 22:21:52.293174:CID-2:RT: find flow: table 0x42686e08, hash 12619(0xffff), sa 10.10.10.202, da 100.96.30.30, sp 0, dp 2967, proto 1, tok 20486 Jan 15 22:21:50 22:21:52.293174:CID-2:RT: no session found, start first path. in_tunnel - 0, from_cp_flag - 0 Jan 15 22:21:50 22:21:52.293174:CID-2:RT: flow_first_create_session <snip> [I][B]## Destination NAT happens as expected[/B][/I] Jan 15 22:21:50 22:21:52.293174:CID-2:RT: chose interface fe-0/0/0.0 as incoming nat if. Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_first_rule_dst_xlate: DST xlate: 100.96.30.30(2967) to 10.30.30.30(2967), rule/pool id 1/32769 [I][B]## Correct opposing VRF is chosen for the route lookup[/B][/I] Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_first_routing: vr_id 4, call flow_route_lookup(): src_ip 10.10.10.202, x_dst_ip 10.30.30.30, in ifp fe-0/0/0.0, out ifp N/A sp 0, dp 2967, ip_proto 1, tos 0 Jan 15 22:21:50 22:21:52.293174:CID-2:RT:Doing DESTINATION addr route-lookup [B]Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_rt_lkup in VR-id: 4[/B] Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_rt_lkup: Found route entry 0x0x45baeac0,nh id 0x267, out if 0x48 Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_rt_lkup: nh word 0xc0010 Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_ipv4_rt_lkup success 10.30.30.30, iifl 0x45, oifl 0x48 [B]Jan 15 22:21:50 22:21:52.293174:CID-2:RT: routed (x_dst_ip 10.30.30.30) from LAN (fe-0/0/0.0 in 0) to fe-1/0/1.0, Next-hop: 10.30.226.22 [/B]<snip> [I][B]## Source NAT happens as expected[/B][/I] Jan 15 22:21:50 22:21:52.293174:CID-2:RT:flow_first_src_xlate: src nat returns status: 1, rule/pool id: 2/32773, pst_nat: False. [B]Jan 15 22:21:50 22:21:52.293174:CID-2:RT: dip id = 5/1, 10.10.10.202/0->100.64.10.202/20979 protocol 58[/B] <mega snip>
We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
And finally routing tables (Sorry Mr. Z you're right I should have posted them first ).
LAN to ACME Firewall
Routing tables for each Vrf, test host of 10.30.30.30 existing in both with different next hops
ACME VRF
ACME.inet.0: 7 destinations, 7 routes (7 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
10.0.0.0/8 *[BGP/170] 01:19:15, MED 0, localpref 100
AS path: 2600 I
> to 10.20.126.21 via fe-0/0/1.0
10.20.20.0/24 *[BGP/170] 01:19:15, MED 0, localpref 100
AS path: 2600 I
> to 10.20.126.21 via fe-0/0/1.0
10.20.126.0/24 *[Direct/0] 04:29:01
> via fe-0/0/1.0
10.20.126.200/32 *[Local/0] 04:29:01
Local via fe-0/0/1.0
10.30.30.0/24 *[BGP/170] 01:19:32, MED 0, localpref 100
AS path: 2600 I
> to 10.30.226.22 via fe-1/0/1.0
10.30.226.0/24 *[Direct/0] 04:29:01
> via fe-1/0/1.0
10.30.226.201/32 *[Local/0] 04:29:01
Local via fe-1/0/1.0
LAN VRF
LAN.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
0.0.0.0/0 *[OSPF/150] 04:17:29, metric 0, tag 0
> to 10.10.10.202 via fe-0/0/0.0
10.0.0.0/8 *[OSPF/150] 04:04:25, metric 0, tag 0
> to 10.10.10.202 via fe-0/0/0.0
10.10.10.0/24 *[Direct/0] 04:29:01
> via fe-0/0/0.0
10.10.10.200/32 *[Local/0] 04:29:01
Local via fe-0/0/0.0
10.10.15.0/24 *[Direct/0] 04:29:01
> via fe-1/0/0.0
10.10.15.201/32 *[Local/0] 04:29:01
Local via fe-1/0/0.0
10.20.20.0/24 *[OSPF/150] 04:08:50, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
10.30.30.0/24 *[OSPF/150] 03:46:47, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
10.100.23.0/24 *[OSPF/10] 04:28:43, metric 2
> to 10.10.10.202 via fe-0/0/0.0
10.202.202.0/24 *[OSPF/150] 04:04:25, metric 0, tag 0
> to 10.10.10.202 via fe-0/0/0.0
172.16.12.0/24 *[OSPF/150] 01:21:22, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
192.168.1.0/24 *[OSPF/150] 04:17:29, metric 0, tag 0
> to 10.10.10.202 via fe-0/0/0.0
202.202.202.202/32 *[OSPF/10] 04:28:43, metric 1
> to 10.10.10.202 via fe-0/0/0.0
224.0.0.5/32 *[OSPF/10] 04:29:04, m
Routing instancesrouting-instances { ACME { instance-type virtual-router; interface fe-0/0/1.0; interface fe-1/0/1.0; routing-options { graceful-restart { restart-duration 120; } inactive: instance-import LAN-to-ACME; } protocols { bgp { local-as 199; graceful-restart { stale-routes-time 10; } group WAN1 { peer-as 2600; neighbor 10.20.126.21; } group WAN2 { peer-as 2600; neighbor 10.30.226.22; } } } } LAN { instance-type virtual-router; interface fe-0/0/0.0; interface fe-1/0/0.0; routing-options { inactive: instance-import ACME-to-LAN; } protocols { ospf { graceful-restart { restart-duration 10; notify-duration 10; } area 0.0.0.0 { interface fe-0/0/0.0; interface fe-1/0/0.0; } } } } } [I][B]## Need this since there is nothing inet.0 currently, mgmt is local.[/B][/I] routing-options { max-interface-supported 0; }We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Thanks for looking at it.
I couldn't use next-table for some reason as it would not accept the VRFs as valid tables, which is pretty odd since I've done similar before on the 5800s. Even though it exists I've been told by multiple Juniper folks to try not to use it as it can cause some odd results.
FBF....now that I should have tried. It may be the missing link since all that seems to be missing is forcing the session to process primarily in the opposing VRF. Even though it's kind've a sledge-hammer/walnut approach at least that way I can make it use the routing-instance I want. Unfortunately this is all on my home lab and I still haven't setup remote access to it. Maybe I can jimmy up something here, minus the backend devices since all i really want at this stage is to get the inter-vrf working without the multiple source+dest nat complications.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
zoidberg
Member Posts: 365 ■■■■□□□□□□
Hmmm, not sure why next-table wouldn't work. You need to specify vrname.inet.0, not just vrname. Also, Junos does prevent you from doing two-way next-tables.... so vr-b cannot have a route saying next-table vr-a.inet.0, at the same time as having vr-a with a route saying next-table vr-b.inet.0. The commit will fail as it does not permit two VRs to point to each other with static routes like that, even if those two routes are not overlapping and will not cause a routing loop, Junos still blocks it.
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Yup that was the issue (2 way is needed for something like this, and that is why it hates it).
I've been hitting the lab too hard since last week with home and remote rental and am exhausted. TBH I kept making so many stupid mistakes last night that I could catch it's entirely possible I've missed something else - case in point being having to use fully qualified VRF names for next-table, and not doing so...DUH....I know this but yes I missed it, with the 2 way requirement though it wouldn't have worked but I should have spotted it straight away regardless.
I have another Inetzero session tonight but I think I'll hit the sack for a few hours when I get home first, then do a short one and then just relax for the next day or 2.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
zoidberg
Member Posts: 365 ■■■■□□□□□□
So if I'm following this… in your failure example…. traffic comes into vr LAN, translates, does a route lookup in vr LAN, mission failed. I think the missing piece is there is no reason for it not to look at vr LAN when doing a route lookup. Why would it arbritarily pick vr ACME for a route lookup? It will do the lookup in the vr it was received in, unless you tell it otherwise, and if I'm reading the fe-1/0/0, 1/0/1, 0/0/1, 0/0/0s properly and not being all dyslexic, that's not happening. I think you need to get a route (static or leaked) into vr LAN from vr ACME that uses a vr ACME interface as egress. Then, I believe it would have worked for you.
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Yup that is exactly why it fails, Static NAT happens pre-lookup so it's following default behavior. The problem though is since both sides are overlapping we can't use routing to solve the problem (I had played with different forms of instance importing just in case and it just breaks everything). I presumed/hoped the 'from instance' parameter for Static NAT was a special code set that could intelligently realize it needed to cross VRFs. (kinda like setting a destination prefix of 'inet' for NAT64)...even though there's nothing else that would make it do so.
This is how the process is written in the O'Reilly book, online Juniper docs and even the AJSEC courseware. But none of them mention how they route it (which is where my hope in there being special code came from, I mean they couldn't ALL just be presuming it'll work could they
). We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
I think I found what was missing, in the static-nat prefix statement you can append the target VRF, this wasn't in the O'Reilly example (and I don't think it was in the AJSEC example either, but I'll have to check).
From Juniper Networks - [SRX] Configuration Example - Overlapping IP address space at two sites separated by a single SRX series device - Knowledge Basesecurity { nat { static { rule-set A-B { from routing-instance OrgA; rule A { match { destination-address 2.2.2.0/24; } then { [B]static-nat prefix 192.168.1.0/24 [U]routing-instance OrgB; [/U][/B] } } } rule-set B-A { from routing-instance OrgB; rule B { match { destination-address 1.1.1.0/24; } then { [B]static-nat prefix 192.168.1.0/24 [U]routing-instance OrgA; [/U][/B] } } } } } }We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
zoidberg
Member Posts: 365 ■■■■□□□□□□
hmmm, ya, that might do it for you. rarely see that flag so i forgot about it.
i don't recall ever seeing that in the book or the classes. i think it falls more towards corner cases that are not really covered in standard training.
or aldur has been slacking off on his course writing! aldur, didn't you claim to beef up the srx nat stuff -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
It works, I'll post final details later for completeness but I just disabled Destination and Source nat, re-enabled Static and added those 2 statements to the prefix config and it worked straight away.
Aldur, you need to update sections 5.41 and 5.42 of the AJSEC guide (and let the O'Reilly folks know)
Now to the InetZero lab...We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
zoidberg
Member Posts: 365 ■■■■□□□□□□
Sweet. That's awesome that it works like that. I may need that one day.
I wonder if that would have been a work around for my bug. If I specified the VR like that (which my configuration should not have needed), would it have properly looked at the VR table vs inet.0 like the bug causes? Almost worrth testing. Though, I think I might have tested that. I don't know. 2 years ago seems like a lifetime these days. -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
After all that I only ended up doing a few hours of the next InetZero task, this one was on VPNs. It was a pretty good little lab, mixing Policy/Route and multi-hop with some other SRXs and NAT in the way on a few segments. I needed a refresher on the std. site-site stuff anyway but I mad a point of focusing on ways to speed things up, when it was faster to copy/paste/replace vs. doing sections from scratch and so on - "load merge terminal relative" is your friend here. I didn't finish all of it, just too tired and I'm taking a break tonight. But next session is on Sunday I'll mainly focus on reading until then. We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Nearly forgot, I said I'd post the most relevant configs (just in case someone else gets into the same situation).
[B][edit security nat static][/B] rule-set ACME-NAT { from routing-instance LAN; rule DOUBLE-NAT-ACME { match { destination-address 100.96.30.30/32; } then { static-nat { prefix { 10.30.30.30/32; routing-instance ACME; } } } } } rule-set LAN-NAT { from routing-instance ACME; rule DOUBLE-NAT-LAN { match { destination-address 100.64.10.202/32; } then { static-nat { prefix { 10.10.10.202/32; routing-instance LAN; } } } } rule DOUBLE-NAT-LAN-2 { match { destination-address 100.64.30.30/32; } then { static-nat { prefix { 10.30.30.30/32; routing-instance LAN; } } } } } [B][edit policy-options][/B] prefix-list LAN-NAT { 100.64.0.0/11; 100.64.0.0/12; 100.80.0.0/12; } prefix-list ACME-NAT { 100.96.0.0/11; 100.96.0.0/12; 100.112.0.0/12; } policy-statement ACME-BGP-EXPORT { term ACME-BGP-to-LAN-OSPF { from { protocol static; inactive: prefix-list ACME-NAT; } then accept; } } policy-statement LAN-OSPF-EXPORT { term LAN-OSPF-to-ACME-BGP { from { protocol [ static direct ]; inactive: prefix-list LAN-NAT; } then accept; } } [B][edit routing-instances][/B]ACME { instance-type virtual-router; interface fe-0/0/1.0; interface fe-1/0/1.0; interface lo0.200; routing-options { graceful-restart { restart-duration 120; } static { route 100.64.0.0/11 { next-hop 192.0.2.200; passive; [B][I] ## You need to set the Passive tag to force loading into each VRF to then be able to redistribute it[/I][/B] } } inactive: instance-import LAN-to-ACME; } protocols { bgp { export ACME-BGP-EXPORT; local-as 199; graceful-restart { stale-routes-time 10; } group WAN1 { peer-as 2600; neighbor 10.20.126.21; } group WAN2 { peer-as 2600; neighbor 10.30.226.22; } } } } LAN { instance-type virtual-router; interface fe-0/0/0.0; interface fe-1/0/0.0; interface lo0.100; routing-options { static { route 100.96.0.0/11 { next-hop 192.0.2.100; passive;[B][I] ## You need to set the Passive tag to force loading into each VRF to then be able to redistribute it[/I][/B] } } inactive: instance-import ACME-to-LAN; } protocols { ospf { graceful-restart { restart-duration 10; notify-duration 10; } export LAN-OSPF-EXPORT; area 0.0.0.0 { interface fe-0/0/0.0; interface fe-1/0/0.0; } } } } [B][edit interfaces][/B] fe-0/0/0 { unit 0 { family inet { address 10.10.10.200/24; } } } fe-0/0/1 { unit 0 { family inet { address 10.20.126.200/24; } } } fe-0/0/3 { unit 0; } fe-0/0/4 { unit 0; } fe-1/0/0 { unit 0 { family inet { address 10.10.15.201/24; } } } fe-1/0/1 { unit 0 { family inet { address 10.30.226.201/24; } } } fab0 { fabric-options { member-interfaces { fe-0/0/5; } } } fab1 { fabric-options { member-interfaces { fe-1/0/5; } } } fxp0 { unit 0 { family inet { address 192.168.1.199/24 { master-only; } } } } lo0 { unit 0 { family inet { address 199.199.199.199/32; } } unit 100 { family inet { address 192.0.2.100/31; inactive: address 100.96.255.254/11; } } unit 200 { family inet { address 192.0.2.200/31; } } }
Resultant Routing Table:
ACME.inet.0: 9 destinations, 9 routes (9 active, 0 holddown, 0 hidden)
Restart Complete
+ = Active Route, - = Last Active, * = Both
10.0.0.0/8 *[BGP/170] 00:40:40, MED 0, localpref 100
AS path: 2600 I
> to 10.20.126.21 via fe-0/0/1.0
10.20.126.0/24 *[Direct/0] 02:28:30
> via fe-0/0/1.0
10.20.126.200/32 *[Local/0] 02:28:33
Local via fe-0/0/1.0
10.30.30.0/24 *[BGP/170] 00:40:40, MED 0, localpref 100
AS path: 2600 I
> to 10.20.126.21 via fe-0/0/1.0
10.30.226.0/24 *[Direct/0] 02:28:34
> via fe-1/0/1.0
10.30.226.201/32 *[Local/0] 02:28:37
Local via fe-1/0/1.0
100.64.0.0/11 *[Static/5] 00:44:14
Reject
192.0.2.200/31 *[Direct/0] 00:44:13
> via lo0.200
192.0.2.200/32 *[Local/0] 00:44:13
Local via lo0.200
LAN.inet.0: 14 destinations, 14 routes (14 active, 0 holddown, 0 hidden)
+ = Active Route, - = Last Active, * = Both
10.0.0.0/8 *[OSPF/150] 00:44:13, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
10.10.10.0/24 *[Direct/0] 02:28:30
> via fe-0/0/0.0
10.10.10.200/32 *[Local/0] 02:28:34
Local via fe-0/0/0.0
10.10.15.0/24 *[Direct/0] 02:28:34
> via fe-1/0/0.0
10.10.15.201/32 *[Local/0] 02:28:37
Local via fe-1/0/0.0
10.20.20.0/24 *[OSPF/150] 00:44:13, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
10.30.30.0/24 *[OSPF/150] 00:44:13, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
10.100.23.0/24 *[OSPF/10] 00:44:08, metric 2
> to 10.10.10.202 via fe-0/0/0.0
100.96.0.0/11 *[Static/5] 00:31:09
Reject
172.16.12.0/24 *[OSPF/150] 00:44:13, metric 20, tag 0
> to 10.10.15.20 via fe-1/0/0.0
192.0.2.100/31 *[Direct/0] 00:44:14
> via lo0.100
192.0.2.100/32 *[Local/0] 00:44:14
Local via lo0.100
202.202.202.202/32 *[OSPF/10] 00:44:08, metric 1
> to 10.10.10.202 via fe-0/0/0.0
224.0.0.5/32 *[OSPF/10] 02:29:02, metric 1
MultiRecvWe responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Aldur
Member Posts: 1,460
Aldur, you need to update sections 5.41 and 5.42 of the AJSEC guide (and let the O'Reilly folks know)
Good catch on this, we're actually in the middle of fixing a few errata items for the JSEC/AJSEC courses, I'll make sure this gets put on the list."Bribe is such an ugly word. I prefer extortion. The X makes it sound cool."
-Bender -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Just re-attempted the InetZero VPN task set, and it kicked my ass. I redid the policy-based section I had completed before since there was one condition I hadn't allowed for previously, source-nat'ing on an intermediate SRX cluster for one of the VPN endpoints. To be fair the reason I hadn't done it previously is it wasn't explained properly in the task. The task just mentions that the SNAT is taking place at that point, so I went ahead and allowed for NAT-T and so on, worked fine first time. But when I went through the results/verification section it mentions that there was a file to be loaded to put specific NAT in place....kinda late at that stage. Anyway I knew about it this time so I loaded it on and went to work. I missed setting the local-identity explicitly for the dynamic portion but other than that it was okay.
Next up was the Route-based section. I didn't think this would be a problem and initially it wasn't even though it took a fair amount of time just getting the configs together for a triangular mesh. The real issue was OSPF, I could not get it work no matter what I tried. IKE and IPSEC was up, services were allowed, protocols configured all as verified in both the results/verification section of the workbook and when I compared their own end-configs to mine. It just wouldn't work. Absolutely no hellos or otherwise being received by the peers on any link. Now dynamic routing over VPN is something I've not done before so it's entirely possible I missed something but to miss something that the workbook vendor also did? I'll have to do some small scale testing for this during the week. Just work on 2 peers on my own lab.
I did the next task anyway which was just throwing some GRE into the mix and while nothing actually worked route-wise well at least my tunnels came up and 'looked' correct.
Tired, frustrated, but still learned more about which sections are good to copy/paste and replace to speed things up. Besides if it was all easy it wouldn't be worth much...
I have another session with them on Wed. I'll start from the route-based this time.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Yesterday evening was reading time, primarily on Routing namely the "junos-security-swconfig-routing-protocols-and-policies.pdf". I really need to improve my routing knowledge on these units so I've gone back to my previous Inter-VRF NAT scenario, re-IP'd everything/changed some of the routing protocols and will now do it all up again from scratch. Oh and throw in some port-overloading and NAT bypass for variety...should be fun.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Well that was..er...fun. Final result on that scenario:
Cluster in Active/Standby using reths again rather than standalones, we could use conditional advertisement to keep the traffic symmetric with standalones but it just wouldn't scale well, I don't trust dynamic routing to keep traffic off the fabric link efficiently.
2 transit-traffic VRFs with InterVRF NAT for overlapping subnets (a mix of Static for services and Source for client pools), route-leaking between them for non-overlapping.
BGP peering to multiple hosts on either side with re-advertisement of the opposing VRFs NAT Range (static null route) to the peers now using conditional advertisement so that it tracks routes from that opposing VRF as part of the redistribution into the current VRF's BGP system. That gets around the issue of advertisement of VRF-B's NAT range from the cluster to VRF-A's peers even if VRF-Bs peers are all down.
This has been a great exercise, I've learned a ton about dynamic routing and route-policy in JunOS (well a 'ton' about the basics ). Time to move on though.
Tonight is another InetZer0 lab (I'm aiming for at least every Sunday and Wed evenings now, have them booked that way into mid Feb). I'm going to take another stab at the VPN lab but begin at the route-based section. I want to nail it down but at the same time I can't let it become a bottleneck. Soooo, if it doesn't work tonight I'll move on and come back to it in a few weeks after some more tinkering on my own.
Here are some relevant config snippets:
Policies and related elements[edit policy-options] prefix-list IMPORT-ACME-to-LAN { 10.254.255.0/24; 10.255.255.0/24; } prefix-list IMPORT-LAN-to-ACME { 10.254.254.0/24; 10.255.254.0/24; } [B][I]## Allow ACME VRF BGP to export the LAN VRF NAT range to it's peers only if it the tracking conditions are met.[/I][/B] policy-statement ACME-BGP-EXPORT { term LAN-NAT-RANGE { from { protocol static; route-filter 100.64.0.0/11 orlonger; condition [ LAN-TRACKED-ROUTES-1 LAN-TRACKED-ROUTES-2 ]; } then accept; } term LAN-NO-NAT-RANGES { from { prefix-list IMPORT-LAN-to-ACME; } then accept; } term DENY-ALL { then reject; } } policy-statement LAN-BGP-EXPORT { [B][I] ## Allow LAN VRF BGP to export the ACM VRF NAT range to it's peers only if it the tracking conditions are met.[/I][/B] term ACME-NAT-RANGE { from { protocol static; route-filter 100.96.0.0/11 orlonger; condition [ ACME-TRACKED-ROUTES-1 ACME-TRACKED-ROUTES-2 ]; } then accept; } [B][I] ## Export pre-defined list of prefixes that will not be Static-NAT'd between VRFs[/I][/B] term ACME-NO-NAT-RANGES { from { prefix-list IMPORT-ACME-to-LAN; } then accept; } [B][I] ## Block all other prefixes from export to BGP peers[/I][/B] term DENY-ALL { then reject; } } ## Policy to control prefixes that will be leaked from ACME VRF to LAN VRF policy-statement ROUTE-LEAK-ACME-to-LAN { term ACCEPTED-PREFIXES-ACME { from { instance ACME; prefix-list IMPORT-ACME-to-LAN; } then accept; } term DENY-ALL { then reject; } } policy-statement ROUTE-LEAK-LAN-to-ACME { term ACCEPTED-PREFIXES-LAN { from { instance LAN; prefix-list IMPORT-LAN-to-ACME; } then accept; } term DENY-ALL { then reject; } } condition ACME-TRACKED-ROUTES-1 { if-route-exists { 10.254.10.0/24; table ACME.inet.0; } } condition ACME-TRACKED-ROUTES-2 { if-route-exists { 10.255.10.0/24; table ACME.inet.0; } } condition LAN-TRACKED-ROUTES-1 { if-route-exists { 10.254.10.0/24; table LAN.inet.0; } } condition LAN-TRACKED-ROUTES-2 { if-route-exists { 10.255.10.0/24; table LAN.inet.0; } } }
Routing Instancesrouting-instances { ACME { instance-type virtual-router; interface lo0.2000; interface reth1.0; routing-options { graceful-restart { restart-duration 120; } static { route 100.64.0.0/11 { next-hop 192.0.2.2; passive; } } router-id 10.0.20.1; autonomous-system 2001; instance-import ROUTE-LEAK-LAN-to-ACME; } protocols { bgp { graceful-restart { stale-routes-time 360; } group ACME-PEERS { export ACME-BGP-EXPORT; peer-as 2000; neighbor 10.10.20.2; neighbor 10.10.20.3; } } } } LAN { instance-type virtual-router; interface lo0.1000; interface reth0.0; routing-options { graceful-restart { restart-duration 120; } static { route 100.96.0.0/11 { next-hop 192.0.2.1; passive; } } router-id 10.0.10.1; autonomous-system 1001; instance-import ROUTE-LEAK-ACME-to-LAN; } protocols { bgp { graceful-restart { stale-routes-time 360; } group LAN-PEERS { export LAN-BGP-EXPORT; peer-as 1000; neighbor 10.10.10.2; neighbor 10.10.10.3; } } } } }
Source NAT[edit security] nat { source { pool LAN-SOURCE-POOL-1 { routing-instance { ACME; } address { 100.64.40.1/32; } } pool LAN-SOURCE-POOL-2 { routing-instance { ACME; } address { 100.80.40.1/32; } } pool ACME-SOURCE-POOL-1 { routing-instance { LAN; } address { 100.96.40.1/32; } } pool ACME-SOURCE-POOL-2 { routing-instance { LAN; } address { 100.112.40.1/32; } } rule-set LAN-to-ACME { from routing-instance LAN; to routing-instance ACME; rule SNAT-LAN-1 { match { source-address 10.254.40.0/24; } then { source-nat { pool { LAN-SOURCE-POOL-1; } } } } rule SNAT-LAN-2 { match { source-address 10.255.40.0/24; } then { source-nat { pool { LAN-SOURCE-POOL-2; } } } } } rule-set ACME-to-LAN { from routing-instance ACME; to routing-instance [ ACME LAN ]; rule SNAT-ACME-1 { match { source-address 10.254.40.0/24; } then { source-nat { pool { ACME-SOURCE-POOL-1; } } } } rule SNAT-ACME-2 { match { source-address 10.255.40.0/24; } then { source-nat { pool { ACME-SOURCE-POOL-2; } } } } } }
Static NAT[edit security] static { rule-set LAN-to-ACME-Overlap { from routing-instance LAN; rule ACME-Overlap-1 { match { destination-address 100.96.10.0/24; } then { static-nat { prefix { 10.254.10.0/24; routing-instance ACME; } } } } rule-set ACME-to-LAN-Overlap { from routing-instance ACME; rule LAN-Overlap-1 { match { destination-address 100.64.10.0/24; } then { static-nat { prefix { 10.254.10.0/24; routing-instance LAN; } } } }We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Finishing up the Inetzero session a couple of hours early. I did the Dynamic VPN part of the last task, took a read through the relevant section in the AJSEC guide first as I have never configured one before. Made a mess of it but learned a lot going along and fixing it. Another I'll have to focus on pretty hard in the next few weeks. It's not that it's complicated concept wise, it just has you jumping around quite a few different disparate sections and trying to remember which are tied to which. Pretty much like (and what I also hated) about doing similar on the ASA.
I did the next task, NAT. A good mix of Source, Destination and Static with little things thrown in like when and how to drop untranslated destination-nat traffic and the like. At his stage and after all the work on that last scenario at home I think my NAT knowledge is pretty solid so it wasn't hard. I did get fouled up on one task that explicitly called for address-shifting, even though it was Static-Nat, since that's normally a Source-nat procedure I jumped to the verification section to make sure I wasn't going to waste time on errata. Sure enough they really just meant splitting the address pools efficiently and not 'real' address-shifting.
Just 2 more task areas, Attack Mitigation and Advanced Concepts left. I had a quick scan ahead and I think I can get both done in the next session.
After that is the choice to continue and do the super-lab or redo the minis for practice and working again on the problem areas. I'll have to think on it.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Not a lot to report. I was supposed to do an InetZero session last night but blew it off (a mix of it being my birthday....and my poor head recovering from the celebrations the night before). I did to some work on recovering and reconfiguring the Host VMs I had use for the CCIE, so I got my Win2K3 servers back to connected state, did some testing with DNS doctoring and NAT (and odd quirk I found is that the DNS Server itself has to xlated also for the ALG to work on responses). This will allow me to do some testing with PKI (VPNs etc) during the week.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
Humbe
Member Posts: 202
One heck of a thread...
Enjoyed reading it a lot. Good luck getting the certificate ! -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Thanks, glad you're enjoying it.
Nothing new to add, last night was some R&R. I hope to work on VPNs with Dynamic routing this evening.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Well that's he sub-tasks for the InetZero Lab book all finished, did 7 (attack mitigation: Screens, IDP, Management filters etc.) and Extended Topics (Transparent mode and Filter Base Forwarding).
IDP gave me a little trouble as it was very custom signature and group heavy, requiring a lot of knowledge of existing classifiers from the signature sets (existing groups etc.). The actual implementation part wasn't a problem, neither were the other sections.
Since I've never touched and barely studied transparent mode I read through the O'Reilly Security book chapter on it and then go to work, it was actually pretty easy, not much jumping around different sections at all. One thing that did catch me was VLAN translations and how they affect a trunk vlan-id-list. Essentially you don't list the 'from' vlan, but do list the 'to' id in the vlan-id-list . Kinda odd but it has a very clear/explicit message about this if you get it wrong and try to commit (thanks whoever worked on that config sanitisation script ).
FBF was very easy, I've done it a fair bit for work, just have to remember to feed the forwarding instance the direct-routes, the workbook recommended Rib-groups but personally I prefer export-policies since you have much more control.
I think next I'll draw up a list of mini labs I had trouble with and spend 2 more sessions on those then attempt the super-lab.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Took last night off again. These full sessions are draining me too much. As I mentioned above I think I'll do 3 more in the next 10 days, and then stop for a while. I need to focus more on reading up on some areas and doing mini-labs at home, and right now I'm exhausted the night following an 8 hour session so it's dead time anyway. At least until the end of feb, then it'll be back to regular 8 hour sessions until the Lab itself.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
-
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
I've mainly be reading up on IDP again for the last few days, and realised I had badly misunderstood the 'Terminal' rule option. I thought it simply stopped processing when there was a complete match, including attacks/groups. Nope, it essentially only matches on the flow details. That could have been very nasty. So essentially it's a way of stopping processing based on network criteria, not a full policy match. I'll be doing some labwork on this tonight.
Picked up a few more InetZero rack tokens and have booked tomorrow and Sunday. These will be spent on the sub-tasks from the workbook I had trouble with, then do the full lab as planned perhaps for next weekend. After that I think I'm going to try their Graded Mock lab for the end of the month (it became available a few days ago).We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place? -
Ahriakin
Member Posts: 1,799 ■■■■■■■■□□
Had a good run through some IDP processes on Wednesday night, nothing super complicated just setting up custom-attack-groups, modifying policies, setting bypasses etc. I did some reading on the different sensor and detector configuration options through the Junos Software-Configuration-Guide, that can go pretty deep but definitely something you need to at least be aware of if not know off by heart. I need to work more on chain-attacks, still not 100% on those.
Last night was back to the lab workbook. I decided to just redo the basic system setup tasks (addressing, ntp, syslog, snmp, users/classes/permissions etc.). They're not hard but definitely something I want to get my speed up on since it's an excellent opportunity to save time for later tasks.We responded to the Year 2000 issue with "Y2K" solutions...isn't this the kind of thinking that got us into trouble in the first place?
