SSG5 - No route exists but traffic flows

wavewave Member Posts: 342
Hi guys,

I've puzzled as to how the following is working...

I have a Juniper SSG5 in front of a Cisco 2911 which is routing internal traffic. The Juniper has a public IP and is NATing for the 172.16.1.1/30 address (172.16.1.2/30 is the Cisco 2911).

I have a network 10.10.3.0/192 behind the Cisco 2911 and I can ping internet addresses and browse the web.

The Juniper SSG5 doesn't have network 10.10.3.0/192 nor any 10.0.0.0/8 network in its routing table. It does have 172.16.1.0/30 (connected).

When I went to access the management interface and it didn't work from the 10.10.3.0 network I logged in when directly plugged into the Juniper and noticed there was no route. I added 10.10.3.2/32 and I was then able to ping and make configuration changes.

Then removed the host route and I could still browse the web from the 10.10.3.0 network - how is this possible? Seeing as the Juniper doesn't know about this network.

I thought it might be NAT but even if 10.10.3.x was being NATed the Juniper still wouldn't know how do reach that network.

NB:

-there is no NATing on the Cisco 2911.
-there is a default route on the Cisco pointing to the Junier SSG5 - 172.16.1.1
- there is a default route on the Juniper pointing to the public IP gateway of the ISP

Any ideas?

ROUTE Passed 1 May 2012
SWITCH Passed 25 September 2012
TSHOOT Passed 23 October 2012
Taking CCNA Security in April 2013 then studying for the CISSP

Comments

  • pcgizzmopcgizzmo Member Posts: 127
    I'm not sure but I don't know that I would post such specific information on an open forum. You might want to change your IP's to something fictitious. Not that someone couldn't figure out your equipment etc.. but giving the private network behind the firewall isn't a good idea either.

    Not trying to be a butt just lending you what I've learned from personal experience a long time ago.

    Also if I understand correctly it's working as it should. The 2911 is connected to the Juniper and your 10. network is behind the 2911 and is being routed out the 2911 out the Juniper onto the public net.

    Does the 2911 have a default route? 0.0.0.0 0.0.0.0 172.16.1.1
  • wavewave Member Posts: 342
    pcgizzmo wrote: »
    I'm not sure but I don't know that I would post such specific information on an open forum. You might want to change your IP's to something fictitious. Not that someone couldn't figure out your equipment etc.. but giving the private network behind the firewall isn't a good idea either.

    Not trying to be a butt just lending you what I've learned from personal experience a long time ago.

    Err - I already did - they are fictitious.
    pcgizzmo wrote: »
    Also if I understand correctly it's working as it should. The 2911 is connected to the Juniper and your 10. network is behind the 2911 and is being routed out the 2911 out the Juniper onto the public net.

    Does the 2911 have a default route? 0.0.0.0 0.0.0.0 172.16.1.1

    Yes that's correct and yes that default route exists - internet access works fine.

    BUT unless I add a route on the Juniper to 10.10.3.0/192 none of those machines can ping and manage the Juniper firewall itself. I actually just need a host route so one management machine is able to log into the Juniper to configure it etc.

    It seems bizarre that I can access the internet through the Juniper from network 10.10.3.0/192 but I can't hit 172.16.1.1 without specifically adding a route on the Juniper to the 10.x.x.x network

    In theory, when I send a request to the internet the Juniper shouldn't know what to do with the response given there is no entry for that private network in its routing table. But magically it works...

    ROUTE Passed 1 May 2012
    SWITCH Passed 25 September 2012
    TSHOOT Passed 23 October 2012
    Taking CCNA Security in April 2013 then studying for the CISSP
  • sexion8sexion8 Member Posts: 242
    Likely some form of ARP caching. On the following on the ssg

    get arp all | in 10

    I'm betting your info is cached somewhere in which if it is, its likely sending it right back out where it came from. Or you could debug it on the SSG:

    clear db
    set ffilter src-ip YOUR_IP_INSIDE_THE_10_NETWORK
    debug flow basic

    PING FROM YOUR MACHINE IN THE 10 NETWORK

    Back on the SSG
    get db str
    "Everything we hear is an opinion, not a fact. Everything we see is a perspective, not the truth." - Marcus Aurelius
  • wavewave Member Posts: 342
    When I do: get arp all | in 10 I don't see a MAC for 10.10.3.2 cached. However, there is an entry for 172.16.2.2 as expected. This is a different LAN segment so there shouldn't be any entries for the 10.x.x.x network should there?

    Below are three captures. The first shows a failed ping from 10.10.3.2 when there are no routes to 10.10.x.x in the routing table on the SSG5. The second shows a successful ping to Google's DNS server and it looks like some sort of MAC caching was used for the reverse path? As in bold.

    The third capture shows a successful ping to 172.16.1.1 after I added a route to the 10.10.x.x network.

    So for some reason MAC address caching is taking place for the reverse path when pinging a global address, but not for a local interface?

    Thanks in advance, this is helpful for my sanity.

    Failed ping to 172.16.1.1 (SSG5 eth0/1 interface) from 10.10.3.2

    ****** 28004758.0: <Trust/ethernet0/1> packet received [100]******
    ipid = 59848(e9cicon_cool.gif, @038be250
    packet passed sanity check.
    flow_decap_vector IPv4 process
    ethernet0/1:10.10.3.1/4->172.16.1.1/53343,1(8/0)<Root>
    no session found
    flow_first_sanity_check: in <ethernet0/1>, out <N/A>
    [ Dest] 134.route 10.10.3.2->70.1.1.1, to ethernet0/0
    existing vector list 0-3054554.
    create a self session (flag 0x206), timeout=60sec.
    flow_first_install_session======>
    handle cleartext reverse route
    search route to (self, 172.16.1.1->10.10.3.2) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/1
    cached route 0 for 10.10.3.1
    no route to (0.0.0.0->10.10.3.2) in vr trust-vr/0
    ifp2 ethernet0/1, out_ifp ethernet0/1, flag 00000601, tunnel ffffffff, rc 0

    flow got session.
    flow session id 7768
    flow_main_body_vector in ifp ethernet0/1 out ifp N/A
    flow vector index 0x0, vector addr 0x3054554, orig vector 0x3054554
    post addr xlation: 10.10.3.2->172.16.1.1.
    packet is for self, copy packet to self
    copy packet to us.

    Successful ping to 8.8.8.8

    ****** 28005086.0: <Trust/ethernet0/1> packet received [100]******
    ipid = 59891(e9f3), @0393da50
    packet passed sanity check.
    flow_decap_vector IPv4 process
    ethernet0/1:10.10.3.2/0->8.8.8.8/53379,1(8/0)<Root>
    no session found
    flow_first_sanity_check: in <ethernet0/1>, out <N/A>
    [ Dest] 134.route 10.10.3.2->79.1.1.1, to ethernet0/0
    chose interface ethernet0/1 as incoming nat if.
    flow_first_routing: in <ethernet0/1>, out <N/A>
    search route to (ethernet0/1, 10.10.3.2->8.8.8.icon_cool.gif in vr trust-vr for vsd-0/flag-0/ifp-null
    cached route 0 for 8.8.8.8
    add route 134 for 8.8.8.8 to route cache table
    [ Dest] 134.route 8.8.8.8->79.1.1.1, to ethernet0/0
    routed (x_dst_ip 8.8.8.icon_cool.gif from ethernet0/1 (ethernet0/1 in 0) to ethernet0/0
    policy search from zone 2-> zone 1
    policy_flow_search policy search nat_crt from zone 2-> zone 1
    RPC Mapping Table search returned 0 matched service(s) for (vsys Root, ip 8.8.8.8, port 40771, proto 1)
    No SW RPC rule match, search HW rule
    swrs_search_ip: policy matched id/idx/action = 60/21/0x1
    Permitted by policy 60
    dip id = 2, 10.10.3.2/0->79.1.1.1/2252
    choose interface ethernet0/0 as outgoing phy if
    no loop on ifp ethernet0/0.
    session application type 0, name None, nas_id 0, timeout 60sec
    service lookup identified service 0.
    flow_first_final_check: in <ethernet0/1>, out <ethernet0/0>
    existing vector list 1-43fb3c4.
    Session (id:739icon_cool.gif created for first pak 1
    flow_first_install_session======>
    route to 79.1.1.1
    cached arp entry with MAC 000000000000 for 79.1.1.1
    add arp entry with MAC 00222d71f406 for 79.1.1.1 to cache table
    arp entry found for 79.1.1.1
    ifp2 ethernet0/0, out_ifp ethernet0/0, flag 10800800, tunnel ffffffff, rc 1
    outgoing wing prepared, ready
    handle cleartext reverse route
    search route to (ethernet0/0, 8.8.8.8->10.10.3.2) in vr trust-vr for vsd-0/flag-3000/ifp-ethernet0/1
    cached route 0 for 10.10.3.2
    no route to (8.8.8.8->10.10.3.2) in vr trust-vr/0
    ifp2 ethernet0/1, out_ifp ethernet0/1, flag 00000801, tunnel ffffffff, rc 0

    cache src mac in session for reverse direction
    (WAVE NOTE: The cached source MAC would be for 172.16.1.2)
    flow got session.
    flow session id 7398
    flow_main_body_vector in ifp ethernet0/1 out ifp ethernet0/0
    flow vector index 0x1, vector addr 0x1ff2a18, orig vector 0x1ff2a18
    post addr xlation: 79.1.1.1->8.8.8.8.



    Successful ping from 10.10.3.2 after route to 10.10.3.0 network was added on the SSG5


    ****** 28004387.0: <Self/self> packet received [482]******
    ipid = 58072(e2dicon_cool.gif, @02ee6dd4
    flow_self_vector2: send pack with current vid =0, enc_size:0
    processing packet through normal path.
    packet passed sanity check.
    flow_decap_vector IPv4 process
    self:172.16.1.1/23->10.10.3.2/51438,6<Root>
    existing session found. sess token 5
    flow got session.
    acket received [113]******
    ipid = 58104(e2ficon_cool.gif, @02d52c34
    flow_self_vector2: send pack with current vid =0, enc_size:0
    processing packet through normal path.
    packet passed sanity check.
    flow_decap_vector IPv4 process
    self:172.16.1.1/23->10.10.3.2/51438,6<Root>
    existing session found. sess token 5
    flow got session.
    flow session id 7753
    flow_main_body_vector in ifp self out ifp ethernet0/1
    flow vector index 0x2, vector addr 0x1ff2a28, orig vector 0x1ff2a28
    skip ttl adjust for packet.
    post addr xlation: 172.16.1.1->10.10.3.2.
    packet send out to f0f755d0c621 (cached) through ethernet0/1
    p ttl adjust for packet.
    post addr xlation: 172.16.1.1->10.10.3.2.
    packet send out to f0f755d0c621 (cached) through ethernet0/1

    ROUTE Passed 1 May 2012
    SWITCH Passed 25 September 2012
    TSHOOT Passed 23 October 2012
    Taking CCNA Security in April 2013 then studying for the CISSP
  • wavewave Member Posts: 342
    It seems like it has something to do with the set flow parameters. I have: set flow reverse-route clear-text prefer

    If I change it to: set flow reverse-route clear-text always .... I can't ping 8.8.8.8 unless I have a reverse-path route in the routing table.

    I found this Juniper knowledge base article on set flow parameters: Juniper Networks - Behavior of ScreenOS 'set flow' commands in asymmetric routing scenario - Knowledge Base

    It doesn't explain why it will allow the pings to pass through the router (through 172.16.1.1) to the internet and back but not ping 172.16.1.1 itself.

    ROUTE Passed 1 May 2012
    SWITCH Passed 25 September 2012
    TSHOOT Passed 23 October 2012
    Taking CCNA Security in April 2013 then studying for the CISSP
Sign In or Register to comment.