SSG5 - No route exists but traffic flows

wave

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?

pcgizzmo

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

wave

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...

sexion8

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

wave

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(e9c, @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. 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. 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:739 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(e2d, @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(e2f, @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

wave

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.