JuniperForum.com

I asume the MPLS is on a separated interface. You can configure monitoring on the interfaces. This makes the interface go down when the MPLS fails, even if the etherlink to your mpls router stays up. Then you configure to static routes. The primary as allways, the secondary with a higher preference number (> 20). The second link will only be active when first one goes down this way.

You should configure manager-ip on the interface. This address is used as source for tracking, even when the interface is down tracking still works. So the interface comes back up when destination is reachable again.

You're mixing things up.  

set interfaces interface-range uplink_trunk unit 0 family ethernet-switching vlan members vlan1006-trust
set interfaces interface-range uplink_trunk member  ge-0/0/0

So ge0-0/0/0 is by interface-range definition in L2-mode (family ethernet switching) That's why you can't assign an IP address to it. Two ways to fix this:

Place ge-0/0/0 in family inet  or place a L3 interface in the vlan ge-0/0/0 is a member of to do the L3 stuff.

look at prometric site for the fee! http://www.prometric.com/Juniper/default.htm

You can take the specialist without taking associate first for ScreenOS. For the new JUNOS tracks you have to certify junos associate before getting certified on any specialist Junos certification.

I totally agree!

When in doubt where the problems lays there are two things you can do:

First:

Enable logging at the begining of a session on the inbounf policy. Then look at the the close reason for a session. That should make clear hether or not the session was allowed by the firewall. If it show age-out, rst or something like that, it was allowed but closed afterwards.

If this don't help use the real pwer tool: debug:

set a flow filter:

set ff dst-ip <outside address> dst-port 23

start the debug:

debug flow basic

Clear the debug output buffer:

clear db

Now try the telnet session.

Stop the debugging:

undebug all (or simply press the ESC button on the keyboard)

Read the output with:

get db stream.

If it isn't clear: post the output, we're here to help you!

Inta zone policies are only usefull when intrazoneblock on this zone is in place! Check with get zone <name> if block is set you need them. Block is default off in trust, on on every other zone. One tricky thing: setting any global policy overwrites the off setting. In other words when configuring just one global policy you allaws need policies for intrazone traffic.

No problem!

Hi,

that's any easy one. Since the squid is proxy it send out traffic with it's own IP address. So this will work

pol form trust to untrust <ip-squid> any HTTP+HTTPS permit
pol from trust to intrust any any HTTP+HTTPS reject log

Traffic from squid will hit rule one, any other rule two.
Of course this must come before an permit all rule.

I'm a bit out of ideas. Maybe combine source and destination natting in policies, let go of mip and vip ?