SRX

Hi all,

I'm a complete rookie with SRX devices and I figured I'd refresh my Junos training from almost 6 years ago whilst throwing out my poorly supported Netgear consumer router, so please forgive me for asking any stupid questions.

I've been tearing my hair out with this one as the NAT rules seem to be operating as they should but I can't get my private IP network to talk to the internet world. I've set up my SRX110 for ADSL functionality and that side of it works fine. I confirmed this by pinging from the CLI to the outside world, without issue. I've also successfully SSH'ed into the unit from an external IP as well (using my mobile phone on the carrier's data service).

So I'm convinced the internet side of the SRX110 is working as it should.

Likewise, I'm able to ping to all my devices on the LAN from the CLI as well. So the two halves are OK in their isolated worlds.

So why won't the two play nice with each other? I've compared my configuration to bits and pieces of others out in this forum and other forums alike but I'm completely dumbfounded as to what it could possibly be. For the moment, I'm trying to just attack this piecemeal and establish an unprotected connection for the moment and once that's working, I can then start adding in my destination NAT stuff and/or firewall stuff to lock it all down accordingly. In effect, I'm trying to set it up as per my consumer grade Netgear router with its firewall config and then grow from there once I get a little more enthusiastic.

I've attached the config file as well as a sample of my security flow results, which appears like the SRX is dropping packets on the egress side. This was me just trying to ping my ISP's DNS (and getting consistent timeouts).

For what it's worth, I did try using the J-web setup wizard but it doesn't seem to make any provision for setting up the ADSL port, expecting me to assign PPP to one of the 8 FE ports on the front instead. This is why I've stuck with doing everything from the CLI, aside from the objective to get back up to speed with Junos. 🙂

All help appreciated.

Attachment(s)

Juniper Security Flow Session capture.rtf   3 KB 1 version

configuration.txt   8 KB 1 version

Hi,

Is there a reason why you have your external interface in a forwarding instance? The configuration is partially setup for FBF but as you only have one external interface there is no point, just makes it harder to troubleshoot.

remove the routing instance and the rib copy and see how you go. Once you have it working if you need FBF then build the configuration out futher to incorporate this functionality.

Tim

Hi Tim,

Thanks for the reply.

Those were recent additions in my attempts to troubleshoot. Initially, I only had the routing-options set up as follows:

routing-options {
    static {
        route 0.0.0.0/0 next-hop pp0.0;

...but to no avail. So I then scoured the internet for more configuration examples and that's when I added in the additional routing entries as well as the routing-instances chain. With or without them, in place, I'm still stuck. 😕

Does the rest of the configuration seem correct or have I messed up something with NAT, policies and/or zones?

Yep it looks like it should work. Revert the config so you no longer have the routing instance and then try again.

show route terse
ping 8.8.8.8 source 192.168.1.1
show security nat source rule all

* Note the number of translation matches and then ping from your LAN device to 8.8.8.8

show security nat source rule all
show security flow session

* Confirm that the translation matches has increased

If it is still not working, apply a basic data capture; see this link for the configuration to do the flow capture

https://kb.juniper.net/InfoCenter/index?page=content&id=KB16110&smlogin=true

With this output it should be clear what is happening.

Tim

Will do. I don't have access to it at the moment so I'll give it another shot.

At the risk of asking another stupid question, when I bought this new, did I need to buy any additional licensing to get this thing to route or should it have just worked out of the box?

No license required to route, it is ready to go out of the box.

Tim

I knew it would be a stupid question. 🙂

Hi Tim,

The translation matches do steadily increase with each ping attempt from my laptop (192.168.1.9).

Please find attached a copy of the DebugTrace text file. What I'm seeing, if I am barking up the right tree, is that the next hop to the PPP interface pp.0 is carrying IP 8.8.8.8. Shouldn't the next hop be my external IP assigned to me by my ISP? Anyway, I'm sure you'll have a better idea of what to look for compared to me but it truly has me stumped.

Attachment(s)

DebugTrace.txt   87 KB 1 version

The trace is hard to read due to all the extra flows. Can you add extra filters to the basic-datapath.

    packet-filter traf {
        protocol icmp;
        destination-prefix 8.8.8.8/32;
        source-prefix 192.168.1.9/32;
    }

then from the host send only 1 ping request. Then attach the trace and the flow output from 'show security flow session'

Tim

Hi Tim,

I have no idea what I have been doing wrong but it seems like the packet-filter just doesn't work for me. Finger trouble I'm sure. It produces a report containing the matches (and marking them accordingly) but it's still among a sea of noise. Here's what I've got in my config for that: 

traceoptions {
      file DebugTraffic size 10m;
      flag basic-datapath;
           packet-filter MatchTraffic {
               protocol icmp;
               destination-prefix 8.8.8.8/32;
               source-prefix 192.168.1.2/32;
           }
          }   

Anyway, further testing today and I discovered that my computers were resolving DNS, which means they were definitely making some sort of contact with my ISP's DNS IPs. So out of blind luck, I figured I'd try typing in www.google.com in my web browser and lo and behold, it worked. However, none of the websites I clicked on from Google worked. Odd.

I did a little more searching while Google was still working and found that someone else had tried to set one of these up with their TPG service. It turns out the maximum TCP segment size needed to be set and for good measure, I decided to do the MTUs as well.

So I've added these two settings in the [security flow] section:

tcp-mss {
    all-tcp {
        mss 1420;
        }
}
tcp-session {
    rst-sequence-check;
}

Everything sprang to life after that. Even my VoIP telephone, which I didn't need to open any ports for, I'm guessing thanks to stateful inspection and having the fairly relaxed trust-to-untrust NAT rule set established.

That said though, I still can't do any ping tests to the outside world. If I try to ping 8.8.8.8 or anything else for that matter, it still fails. As far as I can tell in the show security flow session, and if I'm interpreting the trace log correctly, it's blocking the pongs after the pings got out but I can't understand why if my configuration seems fine compared to others?

Attachment(s)

DebugTrace.txt   100 KB 1 version

Well now that you have some connectivity, usually when it is intermittent it is likely due to mtu. I do not see any return icmp packets in the flow from 8.8.8.8.

Aug 22 07:09:18 07:09:17.898397:CID-0:RT:<8.8.8.8/39228->X.X.X.X/2352;1> matched filter traf:

Aug 22 07:09:18 07:09:17.898397:CID-0:RT:packet [84] ipid = 35092, @0x423f059e

Aug 22 07:09:18 07:09:17.898397:CID-0:RT:---- flow_process_pkt: (thd 1): flow_ctxt type 15, common flag 0x0, mbuf 0x423f0380, rtbl_idx = 0

Aug 22 07:09:18 07:09:17.898397:CID-0:RT: flow process pak fast ifl 74 in_ifp ge-0/0/0.0

Aug 22 07:09:18 07:09:17.898397:CID-0:RT:  ge-0/0/0.0:8.8.8.8->X.X.X.X, icmp, (0/0)

Aug 22 07:09:18 07:09:17.898397:CID-0:RT: find flow: table 0x48924b78, hash 14957(0xffff), sa 8.8.8.8, da X.X.X.X, sp 39228, dp 2352, proto 1, tok 6

Aug 22 07:09:18 07:09:17.898397:CID-0:RT:Found: session id 0xb4a7. sess tok 6

This is what an incoming flow looks like in the file. My interface just happens to be ge-0/0/0 instead of pp0.

At this point, I would upgrade to the latest recommended junos 12.1X46. 

Tim

I had been meaning to upgrade to the JTAC recommended version from the get-go but it seems my access to any of those downloads is restricted. Maybe it's because I only bought the unit and not a support contract to go with it? At any rate, I've put the question forward to Juniper CSC, so hopefully they'll get back to me soon.

...and many thanks for helping us out. It's much appreciated! I'm sorry I didn't say so earlier.

Hi Tim,

Just thought I'd report back about this ping problem. After pressuring my Juniper reseller for a copy of the 12.1X46-D35 software, since I'd only just bought the unit from them and couldn't justify forking out $250 for J-Care to help out (!), I've performed the upgrade and problem solved!

Weird thing that something so fundamental wasn't functioning in any software release but there you go. 🙂

Now I can finally take a breather before embarking on using the deeper level security features to really lock this network down. 🙂

Once again, many thanks for all your help.