Site-Site issue with SMB, some clients cannot be accessed.

captaintofuburger · Feb 20, 2013, 10:58 PM

Hey guys I'm hoping someone can help me out with this.

I just setup 2 pfsense routers from one building to another with an IPSec site-to-site vpn. It's open, connected, and all traffic is being passed through the firewall on each site, wide open. I can ping and see everything, but SMB shares refuse to work on random machines. Everything worked perfectly before my sonicwall blew up, I never had an access issue.
It has to be a software issue. Most of the problems are with XP machines, but it's not an ipv6 issue since I can disable it on win7 machines and still get access. I don't think it can be a firewall because I can get to some machines just not others. The only thing I can think of is packet loss, and there is some but I don't see why.

Top one is a successful connect to a Win7 machine over the vpn, Bottom is one that hangs and windows claims it can't be found even though it's online

192.168.1.166:
16:49:53.302199 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 0
16:49:53.321305 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64634: tcp 0
16:49:53.321656 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 0
16:49:53.321697 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 159
16:49:53.355274 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64634: tcp 174
16:49:53.355759 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 108
16:49:53.370013 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64634: tcp 174
16:49:53.371625 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 166
16:49:53.387013 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64634: tcp 305
16:49:53.387741 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 589
16:49:53.403112 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64634: tcp 77
16:49:53.403482 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64634 > 192.168.1.166.445: tcp 0
16:49:53.407740 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64635 > 192.168.1.166.445: tcp 0
16:49:53.422848 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64635: tcp 0
16:49:53.423221 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64635 > 192.168.1.166.445: tcp 0
16:49:53.423259 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64635 > 192.168.1.166.445: tcp 108
16:49:53.441221 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64635: tcp 174
16:49:53.442460 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64635 > 192.168.1.166.445: tcp 166
16:49:53.470343 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64635: tcp 305
16:49:53.471194 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64635 > 192.168.1.166.445: tcp 589
16:49:53.487315 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.445 > 192.168.2.100.64635: tcp 77
16:49:53.487810 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64635 > 192.168.1.166.445: tcp 0

192.168.1.81:
16:50:23.505684 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64639 > 192.168.1.81.445: tcp 0
16:50:24.507379 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64640 > 192.168.1.81.445: tcp 0
16:50:24.508603 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64641 > 192.168.1.81.445: tcp 0
16:50:24.509600 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64642 > 192.168.1.81.445: tcp 0
16:50:26.509701 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64639 > 192.168.1.81.445: tcp 0
16:50:27.506756 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64640 > 192.168.1.81.445: tcp 0
16:50:27.508754 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64641 > 192.168.1.81.445: tcp 0
16:50:27.509752 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64642 > 192.168.1.81.445: tcp 0
16:50:32.510150 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64639 > 192.168.1.81.445: tcp 0
16:50:33.503207 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64641 > 192.168.1.81.445: tcp 0
16:50:33.505203 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64642 > 192.168.1.81.445: tcp 0
16:50:33.505240 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.100.64640 > 192.168.1.81.445: tcp 0
16:50:50.575209 (authentic,confidential): SPI 0x0c47bd9a: IP 192.168.2.5.445 > 192.168.1.166.49165: tcp 1
16:50:50.590642 (authentic,confidential): SPI 0x0e8235ff: IP 192.168.1.166.49165 > 192.168.2.5.445: tcp 0

I've tried setting the MTU's to a bunch of settings that should work.

C:\Users\MINE>ping -f -l 1500 192.168.1.81

Pinging 192.168.1.81 with 1500 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 192.168.1.81:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:\Users\MINE>ping -f -l 1472 192.168.1.81

Pinging 192.168.1.81 with 1472 bytes of data:
Reply from 192.168.1.81: bytes=1472 time=47ms TTL=126
Reply from 192.168.1.81: bytes=1472 time=29ms TTL=126
Reply from 192.168.1.81: bytes=1472 time=25ms TTL=126
Reply from 192.168.1.81: bytes=1472 time=21ms TTL=126

Ping statistics for 192.168.1.81:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 21ms, Maximum = 47ms, Average = 30ms

1472 was the max I could get, I tried setting the WAN on both routers to 1472 and below, but the only thing it would do is cause more communication issues.

I have no idea what to do at this point, any help would be amazing.

craigduff · Feb 22, 2013, 4:37 PM

To me that doesnt sound like a pfense issue. I would restart the SMB server.. see if that works… or disjoin the machine from the domain and rejoin... Maybe even give the machine a new SID...

craigduff · Feb 22, 2013, 4:38 PM

anything on the clients Event log? Maybe demain related..

captaintofuburger · Feb 22, 2013, 9:45 PM

I've tried all of those things, I don't think it's a windows SMB issue since it worked before the router change.

I also enabled the no-df option which didn't make a difference either. It's just SMB as far as I can tell though, other protocols work fine.

Edit:

And it does work fine locally, just not over the ipsec vpn…

Edit 2:

face f*%king palm.... windows firewall. Somehow it was turned on again on the problem computers. I don't know how it got re-enabled, when, or why it worked on my old vpn. But I don't care anymore, I've been tearing my hair out for 2 days with this.

Thanks for the help guys, guess it wasn't a pfsense issue. It was the only thing that changed on my network so I assumed it was.