SRX 240 duplex/speed mismatch and Security policies problems - everything blocked.

[ssampier]

I am new to Juniper, so I apologize if this a noobish question.

Here's my issue. I am migrating from a Cisco Pix 515 firewall. It's old, slow, and doesn't do much. It does work, however. I, of course, unplugged my Pix and used the same cables to the Juniper.

On Juniper SRX 240 I have two problems, they may be related or not.

The first problem is occasionally I get amber lights (duplex or speed mismatch) on my Cisco 2950 switch. I set both sides to 100 full duplex, which mostly works. The problem is intermittent, however. Keep in mind these same cables and settings work with my Cisco Pix 515. Is there a compatibility problem between the Juniper and Cisco?

The second problem is from the outside of the firewall, I can't access any of my websites or email; everything is blocked. I can access the internet and everything from behind the firewall.

I checked my security policies and zones. Everything looks fine to me.

I have posted my running config. I replaced the first public octet in the ip address with an x on this forum for security.

[mikep]

Hi,

please try to disable auto-neg (example for ge-0/0/0) to solve your first problem:

set interfaces ge-0/0/0 ether-options no-auto-negotiation

Kind Regards

Michael Pergament

If this worked for you please flag my post as an "Accepted Solution" so others can benefit. A kudo would be cool if you think I earned it. 

[rkim]

I am assuming that you are trying to access servers which have public IPs (no NAT). If you are having issues with traffic getting blocked, try enabling flow traceoptions to get an idea of why the traffic may be dropping.

Example:

set security flow traceoptions file flowtrace world-readable

set security flow traceoptions flag basic-datapath

set security flow traceoptions packet-filter 1 destination-prefix <IP you are trying to reach>

set security flow traceoptions packet-filter 2 source-prefix <same IP as above>

Commit the configs and then check /var/log/flowtrace to get an idea of how the SRX is handling the traffic.

-Richard

[ssampier]

Update: I ran that tool and I check /var/log/flowtrace. I think I found my paydirt

Oct 11 15:15:22 15:15:21.1407165:CID-0:RToing DESTINATION addr route-lookup

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT:  routed (x_dst_ip x.119.127.110) fr
om untrust (ge-0/0/12.0 in 0) to ge-0/0/4.0, Next-hop: x.119.127.110

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT:  policy search from zone untrust-> zo
ne trust

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT:  app 21, timeout 1800s, curr ageout 2
0s

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT:  packet dropped, denied by policy

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT:  packet dropped,  policy deny.

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT:  flow find session returns error.

Oct 11 15:15:22 15:15:21.1407165:CID-0:RT: ----- flow_process_pkt rc 0x7 (fp rc
-1)

It looks like it's not finding the right policy. Hmm. It's using the default drop policy. I will triple check my config again.

Message Edited by ssampier on 10-11-2009 02:22 PM

[rkim]

dst_ip x.119.127.110

You don't have an address object for trust zone for x.119.127.110. Hence reason it is not matching any of your permit policies. 

-Richard

[ssampier]

Ok. Now I am more confused than ever. I really have no idea what it is doing. It almost seems like it's trying to use NAT sometimes. Why it would do that, I have no idea.

Oct 11 15:10:35 15:10:34.1100598:CID-0:RT:<209.85.212.27/38513->x.119.127.110/
110;6> matched filter 1:

Oct 11 15:10:35 15:10:34.1100745:CID-0:RTacket [60] ipid = 49462, @4297ad1c

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:---- flow_process_pkt: (thd 2): flow_c
txt type 13, common flag 0x0, mbuf 0x4297ab80

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT: flow process pak fast ifl 71 in_ifp g
e-0/0/12.0

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  ge-0/0/12.0:209.85.212.27/38513->x.119.127.110/110, tcp, flag 2

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT: find flow: table 0x49de8d98, hash 712
2(0xffff), sa 209.85.212.27, da 205.119.127.110, sp 38513, dp 110, proto 6, tok
448

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  no session found, start first path.
in_tunnel - 0, from_cp_flag - 0

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  flow_first_create_session

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  flow_first_in_dst_nat: in <ge-0/0/12
.0>, out <N/A> dst_adr 205.119.127.110, sp 38513, dp 110

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  chose interface ge-0/0/12.0 as incom
ing nat if.

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:flow_first_rule_dst_xlate: DST no-xlat
e: 0.0.0.0(0) to 205.119.127.110(110)

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:flow_first_routing: call flow_route_lo
okup(): src_ip 209.85.212.27, x_dst_ip x.119.127.110, in ifp ge-0/0/12.0, out
ifp N/A sp 38513, dp 110, ip_proto 6, tos 0

Oct 11 15:10:35 15:10:34.1100745:CID-0:RToing DESTINATION addr route-lookup

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  routed (x_dst_ip x.119.127.110) fr
om untrust (ge-0/0/12.0 in 0) to ge-0/0/4.0, Next-hop: x.119.127.110

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  policy search from zone untrust-> zo
ne trust

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  policy has timeout 900

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:  app 8, timeout 1800s, curr ageout 20
s

Oct 11 15:10:35 15:10:34.1100745:CID-0:RT:flow_first_src_xlate: src nat 0.0.0.0(
38513) to x.119.127.110(110) returns status 0, rule/pool id 0/0.

Oct 11 15:10:35 15:10:34.1101122:CID-0:RT:  dip id = 0/0, 209.85.212.27/38513->2
09.85.212.27/38513

Oct 11 15:10:35 15:10:34.1101157:CID-0:RT:  choose interface ge-0/0/4.0 as outgo
ing phy if

Oct 11 15:10:35 15:10:34.1101169:CID-0:RT:is_loop_pak: No loop: on ifp: ge-0/0/4
.0, addr: 205.119.127.110, rtt_idx:0

Oct 11 15:10:35 15:10:34.1101169:CID-0:RTolicy is NULL (wx/pim scenario)

[rkim]

This is normal part of flow processing. During first packet processing we check if any NAT is required (there is not in your case). So this is expected behavior.

-Richard

[ssampier]

I was really frustrated with this. I ended recreating a few of my rules. I was using dns names, so I went to the stand-by of IP addresses. I also noticed I missed an SMTP rule in there. I also recreated a few rules with names with periods.

However, I still could not get any public services to work. I was tired and annoyed. Before I left home for the day, I tried making the Cisco auto negotiate and the Juniper auto negotiate. Still nothing.

Since I was about to leave I tried recabling the Pix, but it did not like those auto settings. So I recabled the Juniper.

A few hours later. I tried checking on things and blam; everything seems to be working, like magic.

[pduffany]

ouch