Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 2 subscribers
  • Views 18329 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

SMB from internal to DMZ not working

dx0001
Maybe i'm blind or stupidity in definition, but i can't get Windows Shares (SMB) working.

The network is configured as following:
Internal 10.2.2.0 / 255.255.255.0
Network2 10.1.1.0 / 255.255.255.0
Network2-Server 10.1.1.3

http/https/ftp/pop3/smtp to Network2 is working fine, but i can't access the shares of the Network2-Server (\10.1.1.3\Public\). The packet filter is configured to allow traffic on ports 445 (and 21,25,80,110,443) from the internal network to the Network2. I tried a DNAT with and without automated packet filter rules, i tried it without DNAT.

What am i doing wrong?


This thread was automatically locked due to age.
Parents
  • 0
    Maybe i'm blind or stupidity in definition, but i can't get Windows Shares (SMB) working.

    The packet filter is configured to allow traffic on ports 445 (and 21,25,80,110,443) from the internal network to the Network2. I tried a DNAT with and without automated packet filter rules, i tried it without DNAT.

    What am i doing wrong?


    You should first test routing with ping/traceroute (setup firewall to allow ping)

    If that's OK:
    Out of memory you have to open the port 445 for w2k and upwards (older systems like windows 9X also use netbios which uses ports somewhere in the 139 range (google)) .
    The easiest way is looking at the packet filter log to see which packet's are dropped.. 

    Good luck,
    Robert
  • 0 in reply to leeuwenrjj
    Thanx Robert,
    as i told port 445 is open and has an "allow-rule" in the packet-filter. All machines connect perfectly using only 445 with blocked NetBIOS when they are in the same network without the Astaro in between.

    Why ping when alle the other services function well?

    As far as i can see the packet filter blocks broadcasts (it always does, when i remember correctly).

    Maybe this forum has some users which have similar network settings and have Windows Shares running. I'd be interested how you did that.
  • 0 in reply to dx0001
    Thanx Robert,
    Why ping when alle the other services function well?

    As far as i can see the packet filter blocks broadcasts (it always does, when i remember correctly).

    Maybe this forum has some users which have similar network settings and have Windows Shares running. I'd be interested how you did that.


    Why ping? I was not sure if the other services are also connecting to this specific machine...
    So always step 1: check routing...
    (although the test with DNAT should circumvent this)

    I had CIFS sharing running at my previous employer... just added the ports no probs....
    In my experience blocked packet's always turn up in the logging (just put the client in the filter and any strange thing should turn up immediately). If this is not the case there is something else wrong.

    Small thing to check: maybe on the windows client or server itself there is a firewall running?

    Good Luck,
    Robert van Leeuwen
  • 0 in reply to leeuwenrjj
    The logfile says that SMB-packets on port 445 are blocked:
    Drop ... 10.2.2.31:1731 --> 10.1.1.3:445....

    But there is a rule which is explicitly allowing this traffic from 10.2.2.x towards 10.1.1.3 (TCP & UDP).

    BTW: The local firewalls are switched to bypass (-->filtering off).
  • 0 in reply to dx0001
    The logfile says that SMB-packets on port 445 are blocked:
    Drop ... 10.2.2.31:1731 --> 10.1.1.3:445....

    But there is a rule which is explicitly allowing this traffic from 10.2.2.x towards 10.1.1.3 (TCP & UDP).


    The dropping of packets seems to be the problem then [:D]
    A rule should look something like this:
    Source Network 10.2.2.X 
    Destination 10.1.1.3
    Dst. Port 445 Src Prt Any (Default this is a CIFS rule)
    Allow
    Don't forget to enable the rule by pressing the button next to the red button...

    Good Luck,
    Robert
  • 0 in reply to leeuwenrjj
    I've got the feeling that i didn't make myself clear:

    The existing and active rule allows CIFS-traffic (TCP & UDP from 1..65535 towards 445) from 10.2.2.x to 10.1.1.3 already!

    And because this rule exists and is active i'm wondering why the ASL drops this traffic.

    To break it down: The configuration for SMB/CIFS is the same on the ASL as is the config for http/https/smtp/pop3/ftp and these protocols are working perfectly.

    Thanx Robert - seems you're the only one replying ;-)
    BTW: Your name sounds like netherlands or so?

    Greetz
    Dietmar
  • 0 in reply to dx0001
    Is there a rule above which could drop these packets ?

    The log shows you by which rule the packets have been dropped.
  • 0 in reply to ClausP
    I've disabled IPS/Proxies and all rules before the CIFS-allow-rule. 

    The log actually doesn't show blocking of port 445 (sorry for my post above which resulted in viewing an old logfile *sigh i'm getting older*)

    Though the WinXP-clients seem to use the TCP 139 for SMB/CIFS i added another rule which allowed that (even though my private network runs pretty well with only 445). Now the filtering rules (60001, packetfilter) for Port 139 disappeard, but still no access to the Windows Shares on the server are possible.

    Still rule 60002 for port 139 is fired, but when i remember correct it should be the autogenerated blocking-rule for udp?
  • 0 in reply to dx0001
    I've disabled IPS/Proxies and all rules before the CIFS-allow-rule. 

    The log actually doesn't show blocking of port 445 (sorry for my post above which resulted in viewing an old logfile *sigh i'm getting older*)

    Though the WinXP-clients seem to use the TCP 139 for SMB/CIFS i added another rule which allowed that (even though my private network runs pretty well with only 445). Now the filtering rules (60001, packetfilter) for Port 139 disappeard, but still no access to the Windows Shares on the server are possible.

    Still rule 60002 for port 139 is fired, but when i remember correct it should be the autogenerated blocking-rule for udp?


    Dietmar,

    Hmm, MS docs say that 445 port should be sufficient for W2K and upwards although other implementations (samba) do still use Netbios on ports 137-139 udp/tcp.

    You could try this method if possible/allowed:
    Create a rule which allows ALL traffic from your test PC IP to the server.
    If this does not work you should probably look at other issues than the filter rules.

    If it works: enable only logging on this rule.
    Check the log to see which ports are hit and enable these with rules.

    Just a thought: maybe name-resolution is a problem. 
    Tried to connect on IP-address? (instead of servername)

    Good Luck,
    Robert van Leeuwen (yes, from Holland [:)])
Reply
  • 0 in reply to dx0001
    I've disabled IPS/Proxies and all rules before the CIFS-allow-rule. 

    The log actually doesn't show blocking of port 445 (sorry for my post above which resulted in viewing an old logfile *sigh i'm getting older*)

    Though the WinXP-clients seem to use the TCP 139 for SMB/CIFS i added another rule which allowed that (even though my private network runs pretty well with only 445). Now the filtering rules (60001, packetfilter) for Port 139 disappeard, but still no access to the Windows Shares on the server are possible.

    Still rule 60002 for port 139 is fired, but when i remember correct it should be the autogenerated blocking-rule for udp?


    Dietmar,

    Hmm, MS docs say that 445 port should be sufficient for W2K and upwards although other implementations (samba) do still use Netbios on ports 137-139 udp/tcp.

    You could try this method if possible/allowed:
    Create a rule which allows ALL traffic from your test PC IP to the server.
    If this does not work you should probably look at other issues than the filter rules.

    If it works: enable only logging on this rule.
    Check the log to see which ports are hit and enable these with rules.

    Just a thought: maybe name-resolution is a problem. 
    Tried to connect on IP-address? (instead of servername)

    Good Luck,
    Robert van Leeuwen (yes, from Holland [:)])
Children
No Data