Hi Kris -
I will try the different timeouts tonight. The MTU sounds like a
stretch to me, since every ping test I have tun is clean at 1472 (mtu
1500) and I have seen no evidence of a fragmented packet, aside from the
RPC which is a packet size of 2048. In addition, if it were actually
necessary to make those changes on every client platform I add to the
network and the server itself because of a very intermittent MTU
fragmentation problem, that would imply to me that something serious is
broken somewhere (and I strongly doubt it is on the T1 lines in question
which have operated flawlessly for several years).
By the way, does anyone know why RPC enforces a packet size of 2048 so
that it is guaranteed to fragment across most WANs, by the way? Is
this just the Microsoft RPC implementation that does this? It seems
incredibly stupid to me to create a protocol that is going to fragment
off the starting block across most LANs and almost any WAN.
The AD configuration is very standard. There is actually one AD "site"
that replicates across 3 DCs. So each LAN knows about the users in the
other LAN as they all belong in the same "scope" (is that the correct MS
terminology?). In sites and services there is a separate subnet for
each LAN with the servers correctly specified. Keep in mind that each
of these LANs operates flawlessly (except for this Outlook -> Exchange
issue) - I have very few events of note in a given month which is
unusual for any MS network I have seen. Replication is clean, file
sharing across the VPN is clean, AD log in works fine, etc.
I'll let you know if IPSEC lifetime changes make a difference, but it
will be a bit hard to tell until next weekend when the bees are away and
I can go back to the IPSEC VPN from the now working RPC over HTTPS for
testing. How do I change the TCP/IP Idle timeout?
Kristian Shaw wrote:
> I've been reading the suggestions and I must admit it seems you've
> tried most of the obvious things. There is no RPC protocol inspection
> in m0n0wall so I don't think its an issue with that and you are
> unlikely to reach the firewalls' state limit of 30k connections.
> However, you could try these settings for the firewall:
> - TCP Idle Timeout: try 86400 (24hrs)
> - IPSEC timeouts: for phase 1 try 86400 (24 hrs) and for phase 2 try
> 3600 (1 hr).
> Perhaps you also need to start looking at your AD configuration. Have
> you set up different sites for each location and assigned subnets for
> each in AD Sites and Services?