• Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Search
  • Register
  • Login
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 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.

    1 Reply Last reply Reply Quote 0
    • C Offline
      craigduff
      last edited by 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...

      Kind Regards,
      Craig

      1 Reply Last reply Reply Quote 0
      • C Offline
        craigduff
        last edited by Feb 22, 2013, 4:38 PM

        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 Feb 22, 2013, 10:04 PM 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.

          1 Reply Last reply Reply Quote 0
          4 out of 4
          • First post
            4/4
            Last post
          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
            This community forum collects and processes your personal information.
            consent.not_received