06-08-2009 11:38 PM
I m facing problem of outlook connections drop and restore continuously with different intervals in my LAN, scenario details are below:
i have 1 isg-1000 as LAN Firewall, before placing it all was fine and i was using just one subnet for all servers + clients i.e. 150.x.x.x, i have configured 4 zones on ISG-1000 with different subnet / IP addresses
All servers are in Trust
Clients / LAN users are in Untrust
In DMZ there in nothing at the moment
WAN is used for linking WAN Firewall
problem is that after dividing my LAN to different subnets / Zones (Servers and workstations separate) there continuously connection breaks in outloo 2003, Oracle, Terminal services sessions.
i have configured ANY ANY policy for all zones
urgent reply is appreciated
06-09-2009 12:22 AM - edited 06-09-2009 12:23 AM
to be quite honest i don't see the logic in how you have laid out your network... why didn't you use the trusted zone for your workstations, the untrusted zone to go off to your internet pipe, and the dmz for your servers? or alternatively create a new zone/interface for your servers leaving your dmz for anything you wanted to surface out to the internet?
that aside... in your current setup, by default your trust interface will be in nat mode and your untrust interface will be route mode. this means that everything initated from the trusted zone to your untrusted zone (so in your case from your servers to your workstations) will be hidden behind the egress (untrusted zone) ip address. that might not be playing nice with your environment. see what happens if you try putting both your interfaces in route mode so everything appears from their real ip addresses.
also, confirm you have a policy both from trust > untrust for the services you need, and also an additional matching policy from untrust > trust. not sure there is a huge amount of point in having such a nice device in your lan if you are just going to utilise any/any/any policies!
hope this helps!
p.s. how comes you are using public ip addressing for all your internal lan's?
06-09-2009 02:37 AM
first of all thanks for reply.
We have separate network for Internet that's why we are using untrust for Internal users as all users on this network are internal, threats can be interal too..
I have already tried with Trust (NAT) and Untrust (Route) but nothing happened fruitful.
I have made ANY ANY Policy both sides (Trust to Untust) and (Untrust to Trust)
We are not going to utilize just ANY ANY Policy its actually in testing mode, i have to refine policies but after removal of outlook connection drops problem
Thanks / Regards,
waiting for your reply in this regard
06-09-2009 10:16 PM
Is that 6.1r1? We had some issues with 6.1r1 cos its the first release so its best to upgrade to latest 6.1r5.
It may help some but may not totally resolve all your problems. Your traffics going to be going from untrust (LAN) to go to the trust (servers) right?
In many cases, I have seen that the sessions especially the keepalives to the DC or for the Outlook get lost as the session has timed out on the firewall.
Try this KB, to extend the timeout for some specific Microsoft UUIDs to see if that works for you. If it does then you can finetune:
Note that the KB suggests timeout for certain services to be extended to 1 hr. But this number is just a guide as it differs depending on the network latency.
06-10-2009 01:16 AM
One off topic suggestion. If your IP scheme really is 150.x.x.x., 181.x.x.x, etc. then reconsider the adressing scheme today.
If it does not trouble you today, it will in the near future. Use private space addresses or real ip addresses you own.
If you have FAT client Outlook/Exchange connections, then firewalling this will be a hard task. The client server connection
is using RPC and highports (>1024) to connect. You would have to open these ports to the Exhange server(s).
Do the Exchange connections drop after a specific amount of time; say 30 minutes? You could solve this by enabling some sort
of Keepalive on the Client - Server connection. I know that some MS (and other) protocols pretend to think that TCP sessions last