Netscreen-5GT Disable Proxy ARP

[joelrob]

We have a Netscreen-5GT at a remote site that connects to the main office over IPSec VPN. Outlook users are unable to stay connected. Microsoft says it's because of the Proxy ARP on the firewall, but I don't see anywhere to disable it.

Does anyone know where it's located? It's running ScreenOS 5.4

Thanks in advance.

 

[MaxPipeline]

I doubt this is due to proxy arp. What version of 5.4 are you running? I would recommend the latest which is 5.4.0r3a although 5.4.0r4 will be releasing very soon.

 

[joelrob]

it is 5.4.0r3a.

Opened a case with microsoft, on the exchange server we're getting errors that the clients are opening too many MAPI sessions (more than 32) and then it times out. Replaced the 5GT with a 5XP and it works fine. Put the 5GT back, same problem.

 

[Packet7]

Hello,

This Juniper KB may help. If the MTU does work, there may be an Exchange predefined service. This is configured with the appropriate settings for Exchange, so I would add another rule and test. Are your Exchange users configured in cache mode? Keep me posted.

Solution

Steps to resolve:

1. Makes sure flow, MTU, and MSS settings are fine tuned to avoid fragmentation. The following settings have helped in a number of environments, but you may need to tune these settings differently for your environment.

set flow tcp-mss
unset flow tcp-syn-check
unset flow tcp-syn-check-in-tunnel
set flow all-tcp-mss 1350
set flow tcp-mss 1350
set flow max 1250
set flow path-mtu


2. Make sure above settings match both on the local and remote IKE gateways using the 'get config | inc flow' or 'get flow' command.



3. If the above does not help, there may be an issue with the MS RPC communication. The Microsoft Exchange server communication uses the MSRPC protocol. If the clients performing the MS RPC communication are using a policy on the NetScreen with the ANY service, then upgrade to ScreenOS 5.3.0r4, or as a work-around configure the clients to use a policy with a specific service MS-RPC-ANY.

Rgds,

John

 

[joelrob]

Yes, the users are in cached mode. Do you have the Juniper kb # so I can read the entire article? Any further testing will have to be done in an lab environment as I swapped out the 5GT with a 5XP. The users have been up and running ever since with no disconnects, so it's something to do with the 5GT in particular. Juniper says there is no such thing as Proxy-ARP on their firewalls, Microsoft will no longer troubleshoot the issue since swapping the firewalls out resovled it.

I will try your suggestions though, I have a lab setup. Would like the kb # if you get a chance.

Thanks for the input.

 

[joelrob]

Have found a solution on one of Microsoft's forums that seems to have fixed the issue, here's the link:

http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1137063&SiteID=17

was these settings in particular:

1. Modify the service timeouts as below:
set service MS-EXCHANGE-DATABASE timeout 200
set service MS-EXCHANGE-DIRECTORY timeout 200
set service MS-EXCHANGE-INFO-STORE timeout 200
set service MS-EXCHANGE-MTA timeout 200
set service MS-EXCHANGE-STORE timeout 200
set service MS-EXCHANGE-SYSATD timeout 200
set service MS-RPC-EPM timeout 200
2. Create a new trust to untrust policy at top and include service group ms-exchange and
ms-rpc-epm as below (this assumes you do not already have a policy id 100):
set policy id 100 top from trust to untrust any any ms-exchange permit
set policy id 100
set service MS-RPC-EPM
exit
save


apparently a known issue on the level of code I'm running on the 5GT, not sure why Juniper seemed to know nothing about it.

Thanks for all the input from all.