[vpn-help] Updated package and problem reports

[Matthew Grooms]

Peter Eisch wrote:
> I need to go back over your email from earlier, but I had to be social
> tonight and that can be a chore for me.  Now with alcohol, I don't think I
> could see through it all at the moment.
> 

No worries. All work and no play ... ;)

> When you add the frag'ing on the unencrypted traffic, you're only having the
> tcp stack (in this case) reassemble the payload.  As it does that, the
> checksums will be recalculated and the original [bad] checksum is discarded.
> That will mask the problem.  I don't see frag'ing the unencrypted payload as
> a good thing though.  I don't think remote ip stacks should accept packets
> with incorrect checksums either.
> 

Reassembly is not necessary but a good idea for bandwidth reasons. As 
for the TCP checksum, they don't enter into the picture. [ read below ]

> Walking through a 522b scenario:
>     1) app on client hands off a 3067b message to an established TCP
> connection
>     2) OS routes to client network driver
>     3) vpn stack takes the first 480b of payload
>         - generates a new packet
>         - generates a new checksum
>         - signs and encrypts the packet
>         - routes the encapsulated packet
>       + take the next 480b of payload and repeat
>     4) ack the OS handoff

When performing IP frag/reass, the TCP checksum is never regenerated 
only the IP checksum. The only scenarios where a TCP checksum would be 
bad is if (a) the original checksum was incorrectly generated ( by 
windows in this case ) or (b) the data is not reproduced accurately in 
the fragmented IP datagrams. I think (b) is the more likely scenario.

> To my issue of running checksums and such, I'm still unable to capture in
> logs the unencrypted payload that the OS is handing off to the interface.
> Sniffing with any pcap client (ethereal/windump) only lets me see the
> physical interface and it's traffic.  I'd like to run literal checksum
> checks of what is coming out the other end of the VPN and being put on the
> wire.  Any ideas?
> 

Always ;) When you check any of the three check boxes that say "enable 
packet dump of ..." in the ipsect application the daemon will produce 
pcap files ( not a text decode in the log file ). These cap files 
contain a more or less accurate recording of all traffic related to the 
VPN Client communications. If you want to see the decode or look at the 
hex, open one of the files with ethereal for win32 ;)

Right, so here is the fruit of my labor today ...

Prevent the Virtual network drivers Maximum Packet size from being 
overwritten when the Look Ahead buffer is adjusted by a bound protocol 
driver. This was causing the OS to use a bogus MTU for the adapter and 
my head to ache. ( may require reboot )

Simplify the fragmentation code and remove an unused option that I 
believe may have been causing problems.

Fix for NATT negotiations in main mode.

... and the new install can be found in the usual location.

http://www.shrew.net/vpn/vpn-client-1.0-rc-3.exe

Please let me know if its a winner.

Thanks,

-Matthew