June 22, 2004

Quick notes on IPsec, Samba

I was just setting up a tunnel between home and a client. Home endpoint is kernel 2.6, client’s is kernel 2.4. strongSwan 2.1.2 (I think) at home, FreeS/WAN 2.06 at client’s. Running GRE over IPsec for the tunnel like I usually do. I had the problem where I’d browse from the client’s end to a share on a Samba box at home and it’d hang for a long time when I did anything like right clicking a file or trying to open a file. tcpdump at various points on the path showed that packets were being generated on the GRE tunnel at home destined for the client’s machine, but I don’t *think* I ever saw them leave as ESP packets. I decided this might be an MTU issue, thinking back to my L2TP issue a few weeks back. Kicked the MTU down to 1400, and sure enough everything started working quickly. I don’t exactly know the proper MTU I should be using here. Last week, when doing L2TP, I needed to use lower than 1400. Possibly because of the extra overhead in L2TP.

Also, though I had guest ok = yes on a share on the Samba server, browsing to didn’t work from a Windows 2003 (I think that’s what it’s running) box. It kept prompting for password, I couldn’t hit OK without typing a user name, and it’d just keep bouncing me back to that screen. Hitting “Cancel” canceled the whole operation. I found I had to put map to guest = bad user in the global configuration for the Samba server, which made it map any unknown user to guest. This might be something new in Samba 3.x. I don’t think I’ve seen this in Samba 2.2.x, which I’m running with a similar setup at home, but I also haven’t tested it against Windows 2003. I’ll note that when I hit the Samba 3.x server without map to guest = bad user from my Windows 2000 box here, I can hit OK without typing in a user name or password, but it just keeps presenting that dialog box over and over. My money’s on “change in Samba 3.x.”

Comments are closed.