10-07-2009 11:42 PM
i cannot understand your problem now, what's the problem about adding the route and all the traffic from 10.250.0.0/24 be routed back to fxp0 interface? if you need to route only a few host then you can add a /32 route.
10-08-2009 12:45 AM
Yes there was a missunderstood. But think about that scenario
Untrust some ip address
fxp 10.12.64.3 and .4 / 24
Between Trust and fxp Lan a router with 10.12.64.250 and 10.250.0.250. Nsm with ip 10.250.0.88/24.
Now I am adding a system wide route to the SRX which is like 10.250.0.88/32 via 10.12.64.250 interface fxp0.
The NSM has a route that he can reach 10.12.64.0/24 over 10.250.0.250.
So the request from NSM goes to 10.250.0.250 which routes the traffic to 10.12.64.3 for example. But the replie goes out over Trust interface because destination is 10.250.0.88 and Trust interface is connected directly which means a better metric. So we have asymmetric routing.
I have to tell the box that it should route traffic coming to the fxp, is routed back to the router defined by the backup router command (for that is the command I thought).
Can you understand the problem?
10-08-2009 01:33 AM - edited 10-08-2009 01:34 AM
i understand your problem now, it's so difficult, the firts thing that i think is to change the fxp0 IP for one in the 10.250.0.0/24 subnet, if this is not possible, i'll try a source based-routing, routing all the traffic that comes from 10.250.0.0/24 subnet to interface fxp0, in SCREENOS that was possible but i don´t know if you can do it with JUNOS.
P.S. if you find a solution, let us know!
10-11-2009 06:43 AM
We've been struggling with the same problem for several projects as well. An easy way to solve this is to add a /32 route to reach the NSM via the fxp0 interface, or install the NSM in the management network. But that way it can no longer reach the internet for IDP/schema updates. Even worse, it can't be used to manage remote devices anymore. So thats not really an option in most cases.
On netscreens this can easily be fixed because the devices can be managed inline (manage-ip) or the management interface can be moved to a different virtual router. Neither are possible on the SRX to my knowledge.
Moving all data interfaces to a different virtual router and using the default vr only for management traffic as we had to do on older netscreen versions doesn't work either as VPNs can only be terminated in inet.0 (another annoying limitation for branch deployments).
If anyone has any idea on how to fix this, I'd love to hear it. The usual response is "thats an interesting problem"
02-21-2010 09:18 AM - edited 02-21-2010 09:18 AM
Hi, Does everything find a solution already?Same problem....: All my Netscreen VPN devices which are connected to our SRX cluster needs to be monitored/managed by NSM are routed via the fxp0 interface and routed back to the trust zone on which the packets are denied. If I login on our SA 6000 (sslvpn) which is connected on one of the zones, then I am not able to run the NSM client on my machine. I guess source routing is the only option....anyone?
10-04-2010 06:49 PM
Still looks like a problem today with 10.0 and 10.3. I don't want my management routes in my inet.0 table, but I can't seem to make it work any other way.
10-05-2010 10:51 AM
FYI, with NSM 2010.3 and JUNOS 10.1 (iirc) you can manage the devices in-line.
Other workarounds are of course possible with multiple routing instances - I have several set up that way.