Windows File Sharing DMZ -> LAN Working *Sometimes*??
-
I've tried just about every firewall rule possible to get my linux servers in the DMZ to share samba shares with my windows box, but I can't seem to get it working.
Here are the facts:
-
Windows firewall on my windows 7 64-bit box is completely turned off
-
I've added LAN and DMZ rules to allow TCP/UDP on ports 135-139 and 445 - then I added every rule I could come up with - see image (LAN/DMZ.png)
-
My LAN gateway 10.10.10.250, DMZ gateway 192.168.100.1, Win IP 10.10.10.130
-
The samba machine runs on an ESXi server that is using a virtual setup to control packets –see image attached
-
I can ping the server(s) I'm trying to connect to samba from the win7 machine
-
I can't seem to telnet on ports 139 or 445 from the win7 -> samba linux machine
-
I can ssh to any of these machines from win7
-
I've been trying for a few days
-
I've never been very good at networking
-
I've had a bit of scotch… :P
The strangest part of all this is that file sharing seems to work briefly if I telnet from the linux server to the windows machine (telnet 10.10.10.130 445). Once this initial packet is sent it allows me to log in and navigate the shares. So, I initiate the mapping of the samba share in windows by requesting the UNC in explorer (my computer) \192.168.100.10, then I do the telnet command on the samba machine (telnet 10.10.10.130 445) and file sharing works if I continue to keep the connection alive.
I'm thinking it is because of port triggering, but, like I said, I'm pretty lost when it comes to networking.
Any help would be appreciated. Thanks.
-
-
you could see if there is something blocking traffic from status: system logs: firewall
-
That's a good tip, didn't even know that was there.
Here is what I get when I try to open port 445 from win7 box:
System
May 27 12:17:20 last message repeated 5 times May 27 12:18:36 kernel: arp: 10.10.10.130 is on em0 but got reply from 48:5b:39:70:ff:04 on em1 May 27 12:19:03 kernel: arp: 10.10.10.130 is on em0 but got reply from 48:5b:39:70:ff:ff on em1 May 27 12:19:15 kernel: arp: 10.10.10.40 is on em0 but got reply from 00:1b:78:71:ff:fe on em1Firewall
May 27 12:16:07 WAN 10.10.10.131:137 10.10.10.255:137 UDP May 27 12:16:58 WAN 10.10.10.104:138 10.10.10.255:138 UDP May 27 12:18:02 WAN 10.10.10.104:137 10.10.10.255:137 UDPThe first bit suggests maybe on configuration issue?
The firewall data is pretty strange. Why is it sending to 10.10.10.255 broadcast? And why is traffic going to the WAN at all?
-
just my 2 cent…..
Could it be that wan and lan are on overlapping subnet?
em0 and em1 belongs to?
remove all rules on dmz and only leave the default lan rule on lan.
-
em0 is LAN and em1 is WAN
I've removed all of the DMZ rules and left only the LAN rule with *'s in each position.
It's very strange behavior. Everything has been working fine, http/s, ssh, IMAP/S, etc.
All I wanted to do was allow file sharing from the LAN to DMZ and it's getting all hosed up.
What would be a rule that would allow all DMZ traffic to the LAN and visa versa? Maybe this would help with troubleshooting?
I'm just really confused why it allows port 22, 80, etc, but it would not allow 135-139 and 445.
-
Are you sure that you don't have machines outside of network? as an example: wan side?
Can you take screenshots from your rules?
-
I'm not sure what you mean by 'machines outside of network'.
The most puzzling part of all of this is that I can perform 10.10.10.x -> 192.168.100.x :22/80/443/ect, but I can't do 10.10.10.x -> 192.168.100.x :445/139/etc.
Here are screens of the WAN rules.
-
I did a little peak only(Wife is nagging). Try to also allow UDP traffic.
-
So I should add a rule to allow 445/139/etc on the WAN interface? This is the internet interface though… won't that put my shares on the internet?
-
No don't do that. Good point.
Actually i was interested about LAN and DMZ rules.
-
LAN and DMZ rules are in first post.
Take them with a grain of salt though, I modified the heck out of them to let something through on 445.
-
Okay my last change of knowing a thing:
how you tried to connect just typed \servername\sharename? and you're having what dns and dhcp servers? and do they know each other? so do you have as an example
LAN, 10.10.1.0/24, separate dns-server, separate/internal dhcp-server
DMZ, 10.10.2.0/24, internal dns-server, internal dhpc-serverTo simplify my question, do you happen to have tried to connect with dns or fqdn, but your dns doesn't have A and PTR-records? if thats not it, then i don't know
-
I've circumvented all of that and used the IP to connect. No DNS involved.
For instance, I can connect from 10.10.10.130 to 192.168.100.10 on port 22, but I can't connect to 192.168.100.10 on port 445. If I move the adapter (in vSphere) to the LAN and give it a 10.10.10.x address, everything works fine.
Yeah, it's driving me crazy. Thanks for the help troubleshooting.
-
@0x0:
For instance, I can connect from 10.10.10.130 to 192.168.100.10 on port 22, but I can't connect to 192.168.100.10 on port 445.
This suggests there is something particular about the service on 445 that is causing the connect attempt to fail.
What are you using to make the connection? How is the failure reported? Is there anything in the pfSense firewall log about this attempt?
I don't know how your service on port 445 works. The standard service on that port appears to be microsoft-ds which I presume is microsoft directory services which would probably need to have "outside access" at some stage in which case you would probably need to have firewall rules allowing certain DMZ to WAN access. Its possible you actually are connecting to the service on port 445 and the failure you see is a failure status returned by that service rather than a failure to connect. Does your service on port 445 have a status log you can look at?
I haven't bothered to look at your firewall rules because you "modified the heck" out of the rules you posted. If you have an internal DNS on the DMZ you almost certainly need to allow some sort of access from DMZ to WAN.
I have a Linux server in my DMZ and I can access SAMBA shares (in a WORKGROUP rather than a domain) there from Linux and Windows systems on my LAN through my pfSense box.
-
I used telnet to check for a listening service on that port. (i.e. >telnet 192.168.100.10 445)
Telnet will connect to the port if there is a service listening and it has a path to the host.
For troubleshooting purposes, could you suggest rules on the interfaces that would definitively allow 445?
-
@0x0:
I used telnet to check for a listening service on that port. (i.e. >telnet 192.168.100.10 445)
Telnet will connect to the port if there is a service listening and it has a path to the host.
What does telnet report? There isn't information here to distinguish between a number of different failures. Telnet might "fail" because it receives no response to its connect attempt, its connect attempt was refused, its connect attempt succeeded but it received an "invalid" message from the remote end etc etc.
What is it you are trying to prove?@0x0:
For troubleshooting purposes, could you suggest rules on the interfaces that would definitively allow 445?
Do you know the problem is a firewall problem? As I suggested earlier there might be other reasons why you can't access shares by hostname. Have you checked the firewall log on pfSense to see if its blocking access?
-
That's correct, telnet would fail and you would receive a multitude of failure responses, connection refused, connection timed out, could not open connection to host on port, no route to host, et al. It's a very basic way to test if a service is listening on a host.
I was attempting to rule out the firewall as a problem at this point by opening the needed ports and giving carte blanch access to any traffic between the interfaces.
At no time did I ever suggest that I was attempting to access any host by its hostname - all connections are purely IP based.
Yes, I have checked the firewall log and the states and there is no record of the packets being blocked.
-
@0x0:
That's correct, telnet would fail and you would receive a multitude of failure responses, connection refused, connection timed out, could not open connection to host on port, no route to host, et al. It's a very basic way to test if a service is listening on a host.
If you are getting that variety of responses to your telnet access attempt then I think you should look at the log of the application thats providing the service on port 445. That variety of responses suggests the service is sometimes working and sometimes isn't. Maybe its encountering an error and restarting in an attempt to recover from the error.
-
Ok, so I think I've got this figured out, but I don't know how to solve the issue.
It looks like the issue is that the desktop PC gateway is 10.10.10.1 and the LAN gateway for pfsense is 10.10.10.25.
GATEWAY 10.10.10.1 C:\>tracert 192.168.100.10 Tracing route to 192.168.100.10 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms xxxxxxxxxxxx.com [10.10.10.1] 2 1 ms 1 ms 1 ms xxxxxxxxxxxx.com [173.x.x.x] 3 1 ms 1 ms 1 ms 192.168.100.10 Trace complete.GATEWAY 10.10.10.25 C:\>tracert 192.168.100.10 Tracing route to 192.168.100.10 over a maximum of 30 hops 1 <1 ms <1 ms <1 ms xxxxxxxxxxxxxx.com [173.x.x.x] 2 <1 ms <1 ms <1 ms 192.168.100.10 Trace complete.The attached image is a diagram of my network for the most part. So, my question is; how do I access the samba shares in the DMZ, but still allow me to remote in using VNC to my PC should there be an issue with pfsense that needs to be corrected? Having 10.10.10.1 as my gateway allows me to VNC in and repair/configure pfsense and I don't have to worry about lockign myself out. If I change my gateway to 10.10.10.25, my shares work, but my VNC forwarding from the 10.10.10.1 router breaks. Vice versa, using gateway 10.10.10.1, my VNC works, but my shares don't.
-
Your network configuration strikes me as being a bit unusual. I don't know if thats the final configuration you want or if you happened upon that configuration in an attempt to get something else working. (For a start, your LAN is potentially unprotected by pfSense.)
If you came upon that configuration in an attempt to test internet access to your services then you should be aware that it isn't testing what your cable network adapter will do on access attempts from the internet and you will probably have to test that from the "outside". (Like pfSense, many of this sort of box treat the WAN port as special.)
I think you should move the switch from the pfSense WAN interface to the LAN interface, connect the pfSense WAN interface directly to the cable network adapter and connect the 10.10.10.130 PC to the switch connecting to the pfSense LAN interface.
You don't say what your cable network adapter does. Since you say you have a route in it I'll assume you have it operating as a router rather than a bridge or modem. Many of this sort of device have a rudimentary firewall in which case you will need to configure port forwarding rules for the services you wish to be accessible from the internet (e.g. FTP from the internet , ssh, vnc etc should all go to the pfSense WAN interface IP address) and corresponding port forwarding rules should be setup in pfSense (Firewall -> NAT click on Port Forward tab) to forward these access attempts to the appropriate server.
Perhaps you have combined the pfSense LAN and WAN so you can get access to the the cable network adapter configuration mechanism at 10.10.10.1. I suspect (I don't have suitable equipment to test this) that you could provide such access by configuring a Virtual IP of type IP Alias with IP address 10.10.10.x/24 on the pfSense WAN interface. (See Firewall -> Virtual IPs, click on Virtual IPs tab.) You would need to have a different subnet on the LAN interface first.
-
I agree with wallabybob..
I don't understand why to have firewall wan/lan within same umanaged switch?
I assume that you are trying to use pfsense as an router, because it's placed in the network and not to the edge of it. Am i right?
Or you're doing some sort of test environment inside of network
-
Ok, I'll tinker around with things later tonight in an attempt to conform to your suggestions; however, please keep in mind that the pfsense LAN, WAN, and DMZ are all self contained in a virtual machine running on VMWare ESXi. The server has two NICs, and they both act as switches, not as a traditional NIC - this is just how ESXi operates.
The cable modem is acting as a network adapter (as much as I can get it to) and it is providing DHCP. It's a crappy Comcast SMC business adapter/cable modem and isn't a very robust unit. It has an IP like 173.x.x.6 and pfsense has virtual IPs 173.x.x.1 - 173.x.x.5 using ARP (I'm not 100% sure how that works, but it does.) The pfsense then can allow/deny rules based on the ones on that interface.
There are a few computers, wireless routers and other devices that use 10.10.10.1 as their gateway. I saw no reason for them to use pfsense since it would be a single point of failure. And god help me if netflix goes down while I'm at work and the kids can't watch spongebob… :P
I have the VNC port being port forwarded from the cable modem right to the 10.10.10.130, should my ESXi server fail, I can still access the network to fix things.
I appreciate everyone helping with this, I really figured all this out on my own, that's why my network looks like it is held together with duct tape and magic (because it is...).
-
Hi,
I've the same problem too. the only difference is that LAN is bridged network in order to allow wi-fi connections.
In my case if i go through WLAN then i can reach the samba server in dmz but i'm unable from eth0. no rules in the WLAN/ETH interfaces.
in wireshark i can see dmz traffic in reply to lan requests but service always ask for a password.
samba server has its own dns server, no dhcp.
no problem trough openvpn too.
I'm able to connect on the same server via ssh, vnc, http…
pfsense ver is the yesterday's build.
thank you for the help.