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 1.2.3.4tmp 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.”