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.