Very Computer

Hi,

For the last weeks, i've been debugging a problem with the following setup:

windows 2000 laptop - NAT'ing linux iptables firewall - windows 2000 vpn
server

the vpn solution is standard microsoft ipsec, ESP in tunnel mode
keys are public/private keys based on our company's active directory
(whatever that means).

the many (sometimes) conflicting documents i read about this suggest that it
is possible, under certain circumstances:

- if AH (authentication header) protocol is used, just forget about , not
possible with NAT (not in my case fortunately)
- if ESP is used, it depends if tunnel or transport mode is used.
    for tunnel mode, it should work if client and server agree to do udp
encapsulation (I suppose that they mean that the client and server are NAT-T
compatible).

Our network guys have confirmed me that their solution is indeed NAT-T
compatible

when i try to start a vpn connection while my laptop is behind the nat'ing
firewall, i made the following observations with a network sniffer:

i tried to verify the packet exchange between 2 situations:

1) directly connected, no firewall in between (it works this way)
2)  behind the firewall (does not work).

I noticed (thank you ethereal network sniffer) this:

the first packets that are exchanged seem similar in both cases:

5 packets between client and server, from udp 500 to udp 500
after that 2 fragmented udp packets (i can't see more details about it, not
in ethereal, nor with tcpdump)
then in the 8th packet i see a difference:
this is an isakmp packet (udp 500 to udp 500),

but when the laptop is connected directly, i see in the isakmp part of the
packet,
next payload: key exchange (4), flags: no encryption, no commit, no
authentication

and in the other case (behind firewall),:

next payload: identification (5), encryption, no commit, no authentication

the packet in the ok situation has some other headers like key exchange
payload, nonce payload, certificate request payload, while in the bad packet
, i see none of thease headers (just: encrypted payload: 4432 bytes).

It's as if at that time, the key exhcange is stopped because the NAT'ing
interfered somehow ???

Just for the record, there are NO dropped packets because of firewall
limitations, at least not as far as i could tell.

Any ideas what to do next ?

I'm almost ready to throw in the towel, cause i'm getting buried deep in the
nitty gritty of the ipsec protocol, just thought i'd ask the all-knowing
usenet audience for some ultimate guidance :)

thank you,

Tom.

Quote:> 5 packets between client and server, from udp 500 to udp 500
> after that 2 fragmented udp packets (i can't see more details about it, not
> in ethereal, nor with tcpdump) then in the 8th packet i see a difference:
> this is an isakmp packet (udp 500 to udp 500),

I'm guessing that the fragmentation is due to the use of one or more
large certificates.  If at all possible you want to try and keep the
certificate size down so that fragmentation does not occur.  However,
if you are stuck using a chain two or three deep then there is nothing
you can do about it, you are going to get fragments.

Quote:> but when the laptop is connected directly, i see in the isakmp part of the
> packet, next payload: key exchange (4), flags: no encryption, no commit, no
> authentication

Logically that's actually the second or third message (second if it is
initiator->responder, third if it is responder->initiator) in a main
mode connection attempt.  I'm not sure why you see that after 5
messages.  You should see the sequence :-

    SA  -->
        <--  SA
    KE  -->
        <--  KE
    ID* -->
        <--  ID*

Where the * means the rest is encrypted so you won't be able to see
what it is unless it happens to get logged somewhere by your VPN
client.  If you were using a Pluto, Racoon or ISAKMPD under Linux or
*BSD I could point you to where the log output would be but I've no
idea if your Windows VPN client generates a log, and if so where it
is.  Perhaps your network/tech-support guys can help?

In the case with no NAT firewall then all the above messages would be on
UDP port 500.  However, when you have the NAT firewall, I'd expect to
see the ID messages on UDP port 4500.  Though, whether that happens
depends on how closely the VPN client follows the NAT-T drafts.

If you are using large certificates then I would expect that one or
the other of the ID payloads would result in fragments, the other
packets typically aren't large enough to cause fragmentation.

Anyway, the above is want I'd expect.  I'm not quite sure how to map
your 5/8 messages onto the above.

Quote:> next payload: identification (5), encryption, no commit, no authentication

> the packet in the ok situation has some other headers like key exchange
> payload, nonce payload, certificate request payload, while in the bad packet
> , i see none of thease headers (just: encrypted payload: 4432 bytes).

If the ID payload really is 4432 bytes long then it will get fragmented.

Quote:> It's as if at that time, the key exhcange is stopped because the NAT'ing
> interfered somehow ???

Do you have UDP port 4500 open?  From the above it isn't clear whether
the ID payload you see is being sent by the client or received by it.
It would help diagnosis if you could draw a clear timeline that
indicates each packet sent and received in order and on what ports.