[ previous ] [ next ] [ threads ]
 From:  Jeff Buehler <jeff at buehlertech dot com>
 To:  Kristian Shaw <monowall at wealdclose dot co dot uk>
 Cc:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] RE: RE : [m0n0wall] outlook -> exchange problem
 Date:  Sun, 19 Feb 2006 19:04:09 -0800
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:
> Hello,
> 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?
> Regards,
> Kris.