With our new fiber in place and a couple of extra configs done, it was time to make this our main connection and disconnect the old one… Thinkin this shoulud be a relativly straight forward “replug and play” operation, i went off yesterday switching the connection, adjusting ip’s in dns and the Vpn’s on our firewalls on both our office as the colo-location. Some pinging and tracerouting later , all seemed to be well…
However, early this morning, i started noticing issues with our nightly copy to the backup server in our co-location. Trying to browse servers on the other end gave me a strange issue:
when opening a server and/or share, this was ok as long as there where little files / folders in it. If they had more then about 10, it would fail with the info that “ERROR 65 the network location is no longer available”.. the made me embark on a quest which gave me some (strange) insights into the SMB Protocol.. first of, our setup might be important
Pfsense 1.2 firewalls everywhere both as main firewall as for our “routers”, ipsec between these towards our datacenter.
OpenFiler boxes both in the main office as in our datacenter
Simple Robocopy batches for copying the data.
after looking a lot at forums , i found several posts about PFsense not being able to handle fragmented packets over IPSEC.
Now after switching from xDSL to the fiber, I did not take a look further then the ip addresses of the firewall and for the IPSEC tunnels, however, what i did forget was that the MTU for an xDSL line is 1492.. with our fiber, i did not know for sure..
since PFSense by default takes MTU 1500 for any interface except for PPOE interfaces ( there is automatically sets it to 1492), i started to check some stuff and sure enough, i quickly found out using:
ping -f -l 1500 xxx.mydomain.com
that my packets would get fragmented..
So looking further into it, i found out that MTU 1472 was the best i could find.. but helas.. no luck.. after some further searching i realized that altough my connection was able to handle 1472, IPSEC adds extra overhead data to your packets.. And sure enough, doing a
ping -f -l 1472 to one of my internal ip’s on the datacenter sides, resulted in fragmented packages yet again…
so another search for the best value we could use was done until i found out 1418 was the max MTU over my IPSEC Tunnel..
after this, my samba shares where browseable like they should and the scripts could find the paths again
So kids, want to do Samba browsing over VPN (cause this does not only apply to IPSEC ?) Check your MTU..
Oh.. extra info: apparently (although this was not the case for us), Samba does NOT handle NAT :s
Think i’m going to send a mail to the guys over at Pfsense to see if it is possible to set an MTU for your ipsec tunnel only since now i’m operating below the MTU of my actual connection, just to be able to run samba stuff over it..