OpenVPN S2S works but cannot access CIFS share

raidoh

I've setup OpenVPN Site-to-Site between two SG-2440 boxes over TCP 993 (one of the local verizon routers seemed to be blocking UDP 1194 recently). It seems to be working since I can access both gateways' WebConfigurators via https at the same time. But, I'm having trouble connecting from a Win7 PC at Site B (S2S server) to a CIFS fileserver on the Subnet at Site A (S2S client). I can access the fileserver's web portal via https in a browser but not the shared directories through Explorer.exe, so I was thinking it's a firewall issue instead of a NAT or routing issue but I don't see anything in the Firewall logs of either device to indicate this is correct. I've setup firewall rules to allow TCP/UDP NETBIOS & CIFS ports on 137, 138, 139, & 445 and it works when connected to Site A using a Remote Access OpenVPN connection from individual PCs but not via the S2S connection. What should I be looking for to identify what might be blocking the traffic?

=== Some info on the setup ===

Site A - 192.168.1.0/24
Site B - 172.16.1.0/24
OVPN Remote Access - 10.10.1.0/24
OVPN S2S - 10.0.8.0/24

On Site A I have the following firewall rules on the LAN interface to pass this traffic:
Protocol, Source, Port, Destination, Port
TCP/UDP, LAN net, *, LAN net, NETBIOS (ports = 137, 138, 139, 445)
TCP/UDP, 10.0.8.0/24, *, LAN net, NETBIOS
TCP/UDP, 10.10.1.0/24, *, LAN net, NETBIOS
TCP/UDP, 172.16.1.0/24, *, LAN net, NETBIOS

Site B
Source, Port, Destination, Port
TCP/UDP, LAN net, *, LAN net, NETBIOS
TCP/UDP, 10.0.8.0/24, *, LAN net, NETBIOS
TCP/UDP, 192.168.1.0/24, *, LAN net, NETBIOS

Both devices have a Pass All rule on the OpenVPN interfaces. For the firewall rules, I'm under the impression that traffic goes:
PC (172.16.1.100) –>
Site B LAN interface (172.16.1.1) -->
Site B OVPN interface (10.0.8.2) -->
Site A OVPN interface (10.0.8.1) -->
Site A LAN interface (192.168.1.1) -->
Fileserver (192.168.1.11)

Thanks.

viragomann

I guess the Windows firewall on the fileserver is blocking the access from the other network. You will have to add a rule for this.

marvosa

On a S2S tunnel, the tunnel network is essentially an encrypted transit network, so you can remove "TCP/UDP, 10.0.8.0/24, *, LAN net, NETBIOS" from your firewall rules as nothing will ever traverse the tunnel in that range unless both sides are manually NATing the outbound traffic entering the tunnel, which there's no reason to do if you control both sides.
I'm also not sure what this accomplishes "TCP/UDP, LAN net, *, LAN net, NETBIOS (ports = 137, 138, 139, 445)" as all local traffic will stay on the switch and won't hit the firewall. I'd remove it from both sides.
For CIFS file shares, you only need port 445 open, but that's not your main issue. I'm just noting that you don't need to open NETBIOS ports for a CIFS share. Also, on a routed VPN solution, broadcasts (NETBIOS) don't traverse the tunnel anyway.
How are you accessing your shares?
Have you checked your system logs? Any notable blocks in there? If so, you have a firewall rule issue.
Is AD involved here? Are there different domains on both sides?
What OS is your CIFS share on? You may have a local firewall issue. For example, this is from the firewall on my Win 10 Workstation:

You'll notice by default it only allows file sharing connections from addresses sourced from its local subnet unless you're on a domain. If you're using a server OS, it may be different, but it should be looked at.
TBH, if this is a home connection, I would disable everything and consolidate down to a simple any/any firewall rule until you're making successful connections and then refine from there.
Also, by limiting your protocols to TCP/UDP, you're cutting out things like ICMP, which can be used for troubleshooting

Derelict

Your posted rules show a basic misunderstanding of how pfSense interface rules work in general.

https://doc.pfsense.org/index.php/Firewall_Rule_Basics

https://doc.pfsense.org/index.php/Firewall_Rule_Processing_Order

https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting

When you get that sorted out you can try mounting shares using \ip.add.re.ss\sharename

If that works but you cannot use host names instead of IP addresses you have a DNS issue.

As has already been stated, discovery broadcasts are not routed so you will need to get DNS working correctly.

And double check windows firewall on the target host.

raidoh

Marvosa, thanks for the detailed response. I'll address your questions to try to get to some answers. This afternoon, I was able to get access via IP address by adding pass rules for IGMP multicast addresses which allowed the server authentication traffic from Windows, so that seems to be my firewall issue.

The 10.0.8.0/24 rule was a product of troubleshooting to see if it might help. It didn't, so I can remove it.
LAN to LAN rules are required because I have a Reject All rule. It's my small business router, and I'm using a Pass Needed, Reject All Else logic for the firewall. Maybe that's overzealous, but I'm trying to block malware/viruses sending data out as much as bringing data in. Plus, any/any rules out would make it the same as any Verizon firewall at that point, and that's no fun. ;-)
It's my understanding that 137, 138, 139 are necessary for NETBIOS name services, i.e. broadcasting names for \server\share instead of \IP\share. No?
I access shares via File Explorer and mapped drives. Is that what you're asking?
In the interest of troubleshooting, I've setup to log most of the applied rules and default rules and identified IGMP as a culprit on 224.0.0.1, 224.0.0.22
No AD, just workgroups.
CIFS share is FreeBSD, no software firewall installed on it. The laptop software firewall is set to pass this data.
I did add a temporary any/any rule to identify that it was a firewall issue and found the IGMP issue, but I'm still missing DNS name resolution between the two subnets. I think it might be a gateway issue but am just getting into it.
Good point. I'll add a rule to pass ICMP

Derelict, thanks for the information. I have read those pages, but I probably am missing a lot with my understanding of the firewall rules. I didn't include all the rules in my post. I have a Reject All at the bottom of the list, so I do have to include rules to pass traffic between LAN computers. Once I allowed IGMP to pass the new router, I could mount \ip\share. Now I'm trying to configure DNS to allow access via \servername\share.

Derelict

LAN to LAN rules are required because I have a Reject All rule.

LAN to LAN traffic does not involve the firewall so that rule does nothing.

raidoh

Ok. My misunderstanding. Thanks, Derelict.

Any idea where I should look to get DNS to resolve between the two subnets?

Derelict

If you have a domain controller, tell your workstations to use that for DNS.

If not you need something somewhere to resolve names to inside IP addresses. DNS Resolver and DNS Forwarder have host overrides for that.

If you want, say, server.domain.com to be reached at \server\share you need to be sure domain.com is set in the workstations' search domains.

raidoh

It's a workgroup, so no domain controller. PfSense router is the DHCP and DNS server for each subnet. It serves DNS fine locally and via Remote Access OpenVPN, but doesn't seem to like this configuration. However, DNS Resolver worked when I added the server to the list of Host Overrides.

Thanks!