Screen OS

SSG 20 w/ firmware 5.4.0

 

I have a two untrust zone interfaces on a single trust-vr. One untrust zone is a T1 on the serial1/0.1 interface and the other is a DSL modem on ethernet0/0. I have recently added the DSL and when I plug in the modem to the ethernet0/0, all of my MIPs become inaccessible from the internet. When I remove the DSL they return to normal.

 

What I hope to have is all users on the single subnet trust zone bgroup using the DSL for all internet surfing and leave the T1 to support the external MIPs including the internal terminal server and webserver. I also would like to use the T1 and the DSL as failover for each other.

 

Below are the internet users that I would like to use the DSL through source based routing. The servers and the remainder of network devices should use the T1.

  

Public Access Subnet  66.204.200.80 /28 

Public Access Subnet2  66.204.200.104 /29

Staff Computer Subnet 66.204.200.64 /28  

hmm, Im guessing the DSL pushes down a default route which causes an asymmetric scenario when the MIPs are accessed from the internet.

 

And your question is how to configure SBR? It looks like your internet users are already using public IPs?

Yes, they are public as left behind from a previous ISP who did internal management. We were so ingrained in using the old IPs, I left them the same and Natted them with the SSG 20. 

Heres a KB on how to configure SBR:

http://kb.juniper.net/index?page=content&id=KB4246&actp=search&searchid=1240287184701

 

But I thinkyou  still need to check whats wrong when you plug theDSL in so best way is to runsome debugs:

set ff src-ip X.X.X.X (X isPC trying to access the MIP from internet)

set ff dst-ip X.X.X.X

debug flow basic

-->Run the test to access the MIP

-->Press Esc to stop the debug 

get db str (post this output)

 

Thank you for the reply. I will run the dbug tomorrow and post back. For whatever reason, when the DSL is plugged in, all computers and mapped (MIP) servers automatically switch to the DSL interface for internet access. I can verify this by running tracert and seeing traffic going out the DSL. With the public mapped IP being supplied by the T1's ISP might explain why incoming connectivity is lost. I assume that the MIP servers will have to connect to the internet strictly through the T1 to maintain connectivity. If this is true, then can I assume there is no failover available by virtue of the DSL for my incoming connections, terminal service users and website visitors?

 

Regarding the SBRs, can there be failover for the DSL internet users to use the T1 if the DSL goes down?

The DSL sets the default gateway as a connected route (preference 0) so it will be preferred over any static default route you have set, so all traffic will use this link

 

http://www.corelan.be:8800/index.php/2009/04/19/juniper-screenos-default-route-manipulations-and-redistributions/

 

There won't be failover unless the DSL ISP is the same as the T1 ISP and if they can route the same IP addresses over T1 and DSL

 

For outbound traffic however, you can do failover using track-ip

I did not run the debugs because it looks like c0d3r solved the mystery of the disappearing T1 internet access. 

 

If I set a source based policy for the servers to only use the T1, will this solve all my problems? If so, what are the best metric and preference values to use in the source based policy for the servers to strictly use the T1?

 

Regarding failover, all the internet users that are defaulting to the DSL seem to failover to the T1 when I disconnect the DSL as desired. Do I need to do anything further for configuring failover?

With regards to failover : I don't think you need to do anything else to use the T1 as failover for the DSL

 

The source based routing should do the trick.Just specify the DSL gateway IP in the route and it will work

I don't think you need to set anything special with regards to metrics or preferences, as it is a direct route

 

If the DSL IP is dynamic, then you may have to use a different technique

 

- put the DSL in a separate vrouter (e.g. DSL-vr)

- in the source route in trust-vr, point to vrouter dsl-vr as nexthop

- export the default route from DSL-VR to trust-vr (if you need this DSL-based default route in trust-vr as well)

 

 

Thank you again for all your help in understanding the technicals behind the problem. I believe my problem is fully resolved now. It appears that all that was needed was a source based policy to force the servers to use the T1. The failover is also working as desired.

 

In the previous reply regarding creating a source route policy, I believe c0d3r meant to say T1 instead of DSL where he said "Just specify the DSL gateway IP in the route and it will work"  Also, there seemed to be no need for a source route policy for the DSL confirming what c0d3r said in the previous thread regarding the DSL becoming the preferred route. It ends up that all computers are automatically choosing the DSL that have no other policy enforced on them but also fail back to the T1 destination route automaically when the DSL is disconnected.

 

I did notice that is takes a moment or two longer for the servers to find the policy enforced T1 route when initiating a tracert versus the computers using the DSL. I assume this is the additional time required to read and execute the source route policy.

My last remaining unsolved problem is that the ISP assigned WAN serial interface address is not accessible (pingable) from the internet when the DSL is active and the T1 becomes an inactive route. I think the ISP monitors the T1 with that IP address. I created a source based policy for the router lan IP which gives me access through the router's MIP address but I don't think you can create a SBP for a WAN interface. Any suggestions? 

Are you always going to ping/monitor the T1 WAN serial int IP from the same remote IP address on the internet ?

Perhaps you can set a host route for that IP so you can ping the T1's wan serial int IP.

 

so suppose you want to monitor the T1's IP from 1.1.1.1  then you need to add

 

set route 1.1.1.1/32 gate <T1 default gateway>

 

 

The ISP remotely monitors the WAN serial IP. I am not sure if they always monitor from the same IP.

 

I had too many issues with the source based policy that I had to scrap it. Even though I created policy for the servers to only use the T1, some of my incoming Untust to Trust firewall policies to the servers seemed to quit working and some remote services such as Oracle Clients stopped working.

 

I have placed the DSL in a new untrust-2 zone and I am going to see if I can use firewall policies to control which untrust interface is used by certain devices and services. 

you won't be able to use plain firewall policies to direct routing, however you can do policy based routing for this

 

You could ask your ISP what range of addresses they are using for monitoring, and you can put in a static route for those IP's....

Thanks for the reply. I will try that if that is the olny way. I have also decided that it is not necessary to share the ISP connections, but to let the servers use the T1 and the users use the DSL.

 

Is it correct to say that the SSG 20 cannot segregate two or more interfaces bound to their own separate untrust zones? What if you went as far as creating an additional v-router and placed the separate untrust zones on separate v-routers?

what do you mean with "segregate 2 or more interfaces bound to their own separate untrust zone"

 

Having differently named untrust zones with the T1 bound to one and the DSL bound to the other. Then create firewall policy from one untrust zone for the servers and from the other zone for the internet users.

that should work just fine

just create an additional zone, put it in a vrouter,

 

take the IP off one of the interfaces,

take the interface out of the current zone (by putting it in the new zone)

put the IP back

 

that should do the trick

Before you read my reply (at bottom) let me ask for your thoughts on how to make the T1 the preferred route for the vrouter and then using source based policies for directing general internet users to the DSL. This would keep all current and new critical aplications on the T1 as desired.

 

Answer to your reply

Will I need to create a new vrouter for the DSL? Even with the DSL interface in a different zone from the T1 but still on the same vrouter, the routing entry of IP 0.0.0.0 with a 0 preference and metric 1 automatically push down from the DSL ISP is becoming the preferred active route and ultimately making the T1 gateway inactive. I was trying to at least make the T1 the preferred route for the vrouter and then use policy based routing for the internet users. It appears that a preference of 20 is as low as can be entered for the T1 gateway.

2 possibilities : change the preference of connected routes to e.g. 5 and set the static default route to anything less than 5, or create a vrouter for the dsl, and export the default route to trust-vr

 

http://www.corelan.be:8800/index.php/2009/04/19/juniper-screenos-default-route-manipulations-and-redistributions/

 

To prevent the DSL from inserting itself as the 0 preference default route for the trust-vr, I placed the DSL interface in a separate vrouter named internet-vr.  I can't seem to get the DSL to function when it is on a separate vr from the trust zone. When it is on the same vr, it works. When I take the T1 down, the route ID 50 becomes active but no traffic passes. I even tried adding an additional

set route 0.0.0.0/0 interface adsl2/0 gateway 99.143.127.254 preference 30,  but that didn't help.

ssg20-> get route
IPv4 Dest-Routes for <untrust-vr> (0 entries)
--------------------------------------------------------------------------------H: Host C: Connected S: Static A: Auto-Exported
I: Imported R: RIP P: Permanent 😧 Auto-Discovered
iB: IBGP eB: EBGP O: OSPF E1: OSPF external type 1
E2: OSPF external type 2
IPv4 Dest-Routes for <trust-vr> (10 entries)
--------------------------------------------------------------------------------   ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys--------------------------------------------------------------------------------*  48          0.0.0.0/0    serial1/0.1  64.216.165.117  SP   20      1     Root   50          0.0.0.0/0            n/a     internet-vr   S   30      0     Root*   2   66.204.200.65/32        bgroup0         0.0.0.0   H    0      0     Root*   1   66.204.200.64/26        bgroup0         0.0.0.0   C    0      0     Root*   7  64.216.165.116/30    serial1/0.1         0.0.0.0   C    0      0     Root*   8  64.216.165.118/32    serial1/0.1         0.0.0.0   H    0      0     Root*   5   192.168.202.0/24        bgroup2         0.0.0.0   C    0      0     Root*  32   192.168.200.0/24        bgroup1         0.0.0.0   C    0      0     Root*  33   192.168.200.1/32        bgroup1         0.0.0.0   H    0      0     Root*   6   192.168.202.1/32        bgroup2         0.0.0.0   H    0      0     Root 
IPv4 Dest-Routes for <internet-vr> (3 entries)
--------------------------------------------------------------------------------   ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys--------------------------------------------------------------------------------*   9          0.0.0.0/0        adsl2/0  99.143.127.254   C    0      1     Root*   8  99.143.122.204/32        adsl2/0         0.0.0.0   H    0      0     Root*   7  99.143.122.204/32        adsl2/0         0.0.0.0   C    0      0     Root
ssg20->

 

set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
unset add-default-route
set route 0.0.0.0/0 interface serial1/0.1 gateway 64.216.165.117 preference 20 permanent
set route 0.0.0.0/0 interface adsl2/0 gateway 99.143.127.254 preference 30
set route 0.0.0.0/0 vrouter "internet-vr" preference 30
exit
set vrouter "internet-vr"
exit
set vrouter "untrust-vr"
exit
set vrouter "trust-vr"
exit
set vrouter "internet-vr"
exit

If route id 50 becomes active, looks like its the right behaviour.

 

Can you check the sessions when the T1 link is down?

 

The sessions should be updated with the route ID 50 eg:

 SSG140-> get sess
alloc 5/max 48064, alloc failed 0, mcast alloc 0, di alloc failed 0
total reserved 0, free sessions in shared pool 48059
id 48051/s**,vsys 0,flag 00000000/0000/0001,policy 1,time 2, dip 2 module 0
 if 0(nspflag 800801):X.X.X.X/2771->4.2.2.2/53,17,000c29e91032,sess token 3,vlan 0,tun 0,vsd 0,route 1
 if 7(nspflag 10800800):X.X.X.X/1332<-4.2.2.2/53,17,000c2924b08a,sess token 4,vlan 0,tun 0,vsd 0,route 5

 

That's going to tell us if the route was at least updated in the session.

Next thing since traffic is not flowing is to capture some debugs to see why there is a problem sending the traffic out.

 

set ff src-ip X.X.X.X 

set ff dst-ip X.X.X.X (X is IP for the client initiating the traffic)

debug flow basic

-> intiate traffic

undebug all

get db str (to view output)

 

if you need more info abt how to run debugs pls check:

http://kb.juniper.net/index?page=content&id=KB12208&smlogin=true

 

from AndyC previously.

 

I have not run the debugs yet, but I did create a totally separate vrouter (see route table) and still no connection. I am suspect of my firmware version 5.4.0em8.0. What do you think?

 

IPv4 Dest-Routes for <internet-vr> (5 entries)
--------------------------------------------------------------------------------

   ID          IP-Prefix      Interface         Gateway   P Pref    Mtr     Vsys

--------------------------------------------------------------------------------

*  14          0.0.0.0/0        adsl2/0  99.143.127.254   C    0      1     Root

*   4   192.168.201.0/24        bgroup0         0.0.0.0   C    0      0     Root

*  13  99.143.117.227/32        adsl2/0         0.0.0.0   H    0      0     Root

*  12  99.143.117.227/32        adsl2/0         0.0.0.0   C    0      0     Root

*   5   192.168.201.1/32        bgroup0         0.0.0.0   H    0      0     Roo

Hi

 

looks like em8 is a based off 5.4r3 code. Thats pretty old. I guess if you have a maintenance window, it will be worthwhile to do an upgrade just for a quick test.

 

But, if the route is active, I think still the session was not updated correctly and you can probably check that without really running the debugs.

 

I upgraded to firmware v.6.1.0r5.0 with no change to my problem.

 

With the ADSL interface and the bgroup both in the same (non-default) vrouter, there is no internet access. Even if I make the new vrouter the default router there is no access. If I route to the new vrouter from the default using next hop new vrouter, there is no internet access. The only way to get the DSL to work is to place it in the default original vrouter, which I am trying to avoid for reasons discussed earlier.

 

The only session activity I see when the bgroup and ADSL interfaces are in the new vrouter together is an attempt to make a DNS request as follows:

 

id 7374/s**,vsys 0,flag 00000040/0000/0001,policy 22,time 1, dip 0 module 0
 if 9(nspflag 800801):192.168.201.100/57168->68.94.156.1/53,17,000bcd35eb14,sess
 token 19,vlan 0,tun 0,vsd 0,route 1
 if 21(nspflag 2800):192.168.201.100/57168<-68.94.156.1/53,17,000000000000,sess
token 17,vlan 0,tun 0,vsd 0,route 153

 

Here is the routing table for the new vrouter:

 

IPv4 Dest-Routes for <internet-vr> (5 entries)
--------------------------------------------------------------------------------
------
         ID          IP-Prefix      Interface         Gateway   P Pref    Mtr
  Vsys
--------------------------------------------------------------------------------
------
*       153          0.0.0.0/0        adsl2/0   99.189.55.254   C    0      1
  Root
*         1   192.168.201.0/24        bgroup0         0.0.0.0   C    0      0
  Root
*         2   192.168.201.1/32        bgroup0         0.0.0.0   H    0      0
  Root
*       152    99.189.55.22/32        adsl2/0         0.0.0.0   H    0      0
  Root
*       151    99.189.55.22/32        adsl2/0         0.0.0.0   C    0      0
  Root

ssg20->

 

Here is the policy to access the Untrust-2 ADSL from Trust-2 bgroup0:

 

22 Trust-2  Untrust-2 Any          Any          ANY                  Permit e
nabled ---XXX

 

Here are the interfaces:

 

ssg20-> get interface

A - Active, I - Inactive, U - Up, D - Down, R - Ready

Interfaces in vsys Root:
Name           IP Address                        Zone        MAC            VLAN
 State VSD
serial0/0      0.0.0.0/0                         Null        N/A               -
   D   -
eth0/0         0.0.0.0/0                         Untrust     0017.cbea.0040    -
   D   -
eth0/1         0.0.0.0/0                         DMZ         0017.cbea.0045    -
   D   -
bgroup0        192.168.201.1/24                  Trust-2     0017.cbea.0049    -
   U   -
  eth0/2       N/A                               N/A         N/A               -
   U   -
bgroup1        192.168.200.1/24                  Trust       0017.cbea.004a    -
   U   -
  eth0/3       N/A                               N/A         N/A               -
   U   -
bgroup2        192.168.202.1/24                  Trust       0017.cbea.004b    -
   U   -
  eth0/4       N/A                               N/A         N/A               -
   U   -
bgroup3        0.0.0.0/0                         Trust       0017.cbea.004c    -
   D   -
serial1/0      0.0.0.0/0                         Untrust     N/A               -
   U   -
serial1/0.1    64.216.165.118/30                 Untrust     N/A               -
   U   -
adsl2/0        99.189.55.22/32                   Untrust-2   0017.cbea.0055    -
   U   -
vlan1          0.0.0.0/0                         VLAN        0017.cbea.004f    1
   D   -
null           0.0.0.0/0                         Null        N/A               -
   U   0
ssg20->

 

I am not sure what to try next other than to open a case with Juniper. Any thoughts are appreciated. Thanks.

Hey I was looking at the session and I think the problem may be that since interfaces are in custom zones, you need to have src nat configured on the policy/

 

We can see clearly from the sessio table that the traffic is not getting natted hence, when it gets routed to the internet, the traffic will definitely get dropped.

 

Can you try:

set pol from Trust-2 to Untrust-2 any any any nat src permit

 

 

 

That worked. I am also natted at all the bgroups but it doesn't seem to bother. Instead of using PBR to get certain trust zones to use the DSL, would it be better to simply bind those zones to the Trust-2 in the DSL vrouter? I suppose that in order to get failover to work between vrouters, I will need to create firewall policies with nat src for each zone that I want to failover. From a routing standpoint, when I disconnect the T1, the imported ADSL route comes active in the default vrouter but there is no internet access from any of the trust zones. I have tried natting at the DSL PIM interface and it comes up but the PPPoE won't connect.

 

Thank you again for solving my issue with the DSL.

Bob

Correction to previous post:

I can Nat, but just can't route vs. bridge, at the ADSL interface but still need the policy src nat for internet access. So natting at the interface doesn't help here.

So, for custom zones, interface based natting will not work. That only works for Trust -> untrust or Trust-> dmz kind of zones. For custom zones you need to have policy configured with the src nat.

 

 

To get the "Public Access Computers" in the default vrouter to use the DSL in the second vrouter but still reside on the 192.168.200.0/24 subnet, I first grouped them as follows:

 

set address "Trust" "Public Access Computers" 192.168.200.64 255.255.255.192 "192.168.200.65 - 126 useable"

 

The following policy was set as a default firewall policy for "Public Access Computers" within the default vrouter to provide the proper rules for failover to the default T1 route. (I have not tested the failover yet):

 

set policy id 9 name "Public Access Computer Policy" from "Trust" to "Untrust"  "Public Access Computers" "Any" "ANY" permit log count url-filter

 

To route the "Public Access Computers" to the DSL interface in the custom vrouter, I set a source route entry as follows ( I did not make it permanent hoping that it will fail back to the default T1 route in the home vrouter if the "Next Hop" interface default route drops):

 

set route source 192.168.200.64/26 vrouter "internet-vr" preference 30 metric 1

 

To get things flowing through the source route and between vrouters for the "Public Access Computers", I set the following policy (all sessions are getting logged here)(The ADSL interface is bound to "Untrust-2" in the custom internet-vr)(Notice, this policy is where natting is provided):

 

set policy id 21 name "DSL from Trust" from "Trust" to "Untrust-2"  "Any" "Any" "ANY" nat src permit log count url-filter

 

The following policy got everything flowing for zones within in the custom internet-vr (For whatever reason natting at the DSL interface or the bgroup Interface doesn't seem to take effect, natting within the policy was the only way to get internet access):

 

set policy id 24 name "DSL Users" from "Trust-2" to "Untrust-2"  "Any" "Any" "ANY" nat src permit log count url-filter

 

I am not sure why this works, and there are probably other ways to "skin this cat" but I could never have figured this out without the contributors to this forum. Thank you.