Screen OS

I'm using an SSG5-serial with ScreenOS 6.3 and I have the following problems:

- I'm using two ISP's, no BGP and one of them give me the public IP over DHCP only. If I setup the same IP which is assigned by MAC address the connection is not working anymore.  I would prefer to be static because then I can setup management IP since on DHCP enabled interfaces you cannot use this option.

So my first question is there any reason why is not working if I setup the same IP as static? I'm trying to get my ISP involved but their support is not so good 😞

- if I leave the situation like it is now and leave that interface on DHCP mode bounded to Untrust I'm loosing the access on the second ISP interface which is configured as static, so the device become unmanageable, and is it on a remote location..

My second question: is there a way to avoid this?

At the moment I'm using a second vrouter (Untrust2) where I bound the DHCP interface and also I'm using PBR to have access on the internet . But unfortunatelly the solution is not flexible enough from a redundancy perspective especially and I prefer to have both ISP's on the same Untrust zone and be able to access the router on both interfaces.

Thanks!

Hi,

Are both connections the PPPoEs terminated on the SSG?

Kind regards,

Edouard

No, one is DHCP (the same IP assigned by MAC address) and the second is static IP.

Thanks.

What I'm trying to do now is move the DHCP ISP interface in to trust-vr in order to use ECMP or place the static IP (ISP2) interface into untrust-vr and use ECMP in that vrouter but the main problem that I have with PBR is that even if DHCP ISP interface is a connected route and the local interfaces like DMZ are connected route also - the traffic from local LAN to DMZ tries to go on untrust-vr (ISP with DHCP) since I have ACL's like 192.168.x.x to 0.0.0.0/0 (internet).

basically if I solve this routing issue I can keep the second vr only for internet routing and have PBR from trust-vr to untrust-vr but the local traffic to DMZ is going there also... is there a way to solve this? to basically have all traffic forwarded to untrust-vr (internet) except local DMZ or trust-vr traffic.

Thanks,

George

Hi,

Sorry, I do not have enough information to make a suggestion.  What is your aim and how your requirements are prioritized? Internet access redundancy without a load sharing (a simpler soultion)? Internet access redundancy with a load sharing (a complexer solution)? Why is it impossible to order a static IP by ISP1? The additional fee for this should not be too high. Is PPPoE used for both connections or are both WAN ports connected to the WAN routers? Are public IPs assigned directly to the SSG or NAT is configured on the provider devices and both WAN segments are addressed with the private IPs?

Please post a more detailed description.

Kind regards,

Edouard 

Hi,

Public and static IP is too expensive (indeed I can add some money and take those options too but I'm trying the cheapest solution..)

So, the goal is to have two different ISPs and load balance the connection without BGP, OSPF, etc.

The most important issues so far it was that I couldn't manage the device remotelly by accessing the interface which have the IP assigned over DHCP, but that issue was solved with the VIP trick.

So far I have used that ISP on another vrouter because of the Connected route assigned by screenos automatically because of DHCP. PBR was used in this scenario but unfortunately there are some important limitation when using policy based routing.

The only problem that I still have is why local subnets which have PBR associated to access 0.0.0.0/0 over the second vrouter cannot access local resources from other vlans or dmz? If I'm checking the logs all traffic is forwarded to internet even if the other routes are connected too..

I know that 0.0.0.0/0 means anything but how I can forward traffic from a local vlan to the internet over another ISP from another vrouter?

On the ACL you can only define src xx.xx.xx.xx (local subnet) destination 0.0.0.0/0 (internet) and ports. I did some tricks like forward 80, 443, etc. with PBR in this way I was able to access internet over the second ISP and local shares for example, but I have 80 and 443 in local DMZ too...

Idealy is to have the posibility to define an extended ACL with src, dst EXCEPT dst xx.xx.xx.xx where I can defaine local networks.

In the worst case scenario I will move the DHCP interface in trust-vr (Untrust) and everything will be simple but idealy is to have the internet links in another vr.

I hope I was clear enough this time 🙂

Thanks for help.

Hi,

Thanks! Now I understand more about your configuration/requirements.

You wrote "I have used that ISP on another vrouter because of the Connected route assigned by screenos automatically because of DHCP" Do you mean that this route had precedence over the static DG because of it's "Connected" status? But route preferences can be changed. A "Connected" route has the preference 0 per default. If you change it to 20, that is the default preference of the static routes, the FW will be making routing dessions based on the route metrics of both DGs, that, by-turn, can also be adjusted.

Configuring PBR is a big challenge, indeed, especially if one has to assign multiple extended ACLs to the same match-group and combine everything with the load sharing. The logic behind becomes very complex. In most cases it is a better solution to upgrade the primary link to a higher bandwidth and keep a cheaper secondary link as a backup.

Kind regards,

Edouard

Hi Edouard,

Yes, the route preference can be changed but the DMZ and other VLAN's from trust are connected too,
the IP's are manually configurated and screenos add them by default as being connected. So by changeing route preference options normally won't solve this issue.

Anyway, like you said, configuring and using PBR is a big challange and the whole thing can become too complex to manage.

Now as I can access and manage the device through the DHCP interface I will move it back to Untrust (trust-vr) and then everything is much simple.

Thank you for your feedback.

George

I will answer myself to one of the questions:

if you can't manage an DHCP enabled interface you can create a VIP entry mapped to the DMZ management IP and port (in my case). The VIP entry must have a different port than the management port and then you can create policy to allow traffic and check the Permited IP section too..

Then the unmanaged interface becomes managable!