Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

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

    Scheduled Pinned Locked Moved IPsec
    4 Posts 2 Posters 2.1k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • C Offline
      captaintofuburger
      last edited by

      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.

      1 Reply Last reply Reply Quote 0
      • C Offline
        craigduff
        last edited by

        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...

        Kind Regards,
        Craig

        1 Reply Last reply Reply Quote 0
        • C Offline
          craigduff
          last edited by

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

          Kind Regards,
          Craig

          1 Reply Last reply Reply Quote 0
          • C Offline
            captaintofuburger
            last edited by

            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.

            1 Reply Last reply Reply Quote 0
            • First post
              Last post
            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.