paul at xelerance.com
Sun Dec 4 09:25:59 CET 2005
On Fri, 2 Dec 2005, John A. Sullivan III wrote:
> We've been struggling to get a client who wanted to use the native
> Microsoft IPSec stack managed through the linsys front end
> (http://sourceforge.net/projects/lsipsectool). The tunnel worked great
> but windows kerberos authentication usually failed. To our great
> surprise, we found out the Microsoft excepts Kerberos traffic from an
> IPSec tunnel by default. We need a registry hack to change the default
> behavior as follows:
Yes. The following exemptions (or rather "predefined security holes") exist
in Windows: http://support.microsoft.com/default.aspx?scid=811832
Note that all ipv6 is explicitely allowed to come in from outside IPsec.
Note that this behaviour changed in Windows 2000 SP4 and Windows XP SP2.
I believe it also exempted it from its firewall. There were issues reported
in the past where any packet with a source port of 88 (kerberos) was
explicitely allowed, eg tcp port 88 to the windows port 135 (fileshare).
Other people reported problems with kerberos because it was using UDP,
and they couldn't use TCP clamping to set the maximum MTU on a broken
path-mtu connection. The fix for that is to force Kerberos to use TCP
instead of UDP. See: http://support.microsoft.com/?kbid=244474
> to. It seems that the ESP header size changes depending on the
> encryption algorithm (someone please correct me if I'm wrong) so we set
> it to 1400 to accommodate any algorithm. We could probably have
> squeezed another six to 22 bytes out of it but weren't sure.
That's correct, some ciphers require additional padding.
> We are using WINS but, the windows clients do not appear to be querying
> the WINS servers even if we force them to p nodes.
Note that you will have TCP properties (which contain WINS settings) on
various instances of the tcp stack. L2TP, IPsec, Dailup, Ethernet. You
might be looking/changing the wrong version, or have the wrong WINS server
setting in either the regular DHCP server or the L2TP server's DHCP.
> we resolve it in hopes that someone else struggling to use Openswan and
> linsys this way will not have to reinvent the wheel. If anyone can
> guide us on the browsing issue, we'd appreciate it. We are suspecting
> it has to do either with needing to enable file and print sharing on the
> clients or forcing them to not be browse list servers. Thanks - John
[ old stuff from my head, look up for exact details ]
I believe sometimes you have to add the #PRI and #DOM settings in the
system32\hosts file to trigger proper WINS. This used to be true for
NT and 2000 (without active directory which used DNS, not WINS). Those
entries had a few bugs in them. I know one bug was that some 'first' entry
was ignored. Another bug was that the PRI and DOM entries had to be 16
characters, and might need padding with spaces. These bugs were listed
in the microsoft bug tracker (commonly known as "knowledge base", but
really it is a bug tracker).
Thanks for the report back to the list though!
"Happiness is never grand"
--- Mustapha Mond, World Controller (Brave New World)
More information about the Users