PIX allowing Windows share between DMZ and Inside

Unanswered Question
Mar 4th, 2010

Hello,

I am trying to allow the inside network to be able to use a Windows share (445) created on a server in the DMZ. I have tested the share from another server in the DMZ and it is working. The server in the DMZ (10.0.1.50) and the machine on the inside is (192.168.2.75) that needs to connect a share on the 10.0.1.5.

config on the pix>

access-list acl_inside permit tcp host 192.168.2.75 host 10.0.1.50 object-group SMB

access-group acl_inside in interface inside

object-group service SMB tcp
  port-object eq 445

The inside being NATted when it goes to the DMZ1 but I have also tried the link without NAT.

global (outside) 10 interface

global (intf3_DMZ2) 10 10.0.1.202

nat (inside) 0 access-list 101

nat (inside) 10 0.0.0.0 0.0.0.0 0 0


I ran a capture using just IP so to capture evething between these machines.

21 packets captured
19:14:09.373851 192.168.2.75.4240 > 10.0.1.50.445: S 2252163370:2252163370(0) win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.373943 10.0.1.50.445 > 192.168.2.75.4240: R 0:0(0) ack 2252163371 win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.374141 192.168.2.75.4241 > 10.0.1.50.139: S 744438579:744438579(0) win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.374202 10.0.1.50.139 > 192.168.2.75.4241: R 0:0(0) ack 744438580 win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.871597 192.168.2.75.4240 > 10.0.1.50.445: S 2252163370:2252163370(0) win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.871674 10.0.1.50.445 > 192.168.2.75.4240: R 0:0(0) ack 2252163371 win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.871842 192.168.2.75.4241 > 10.0.1.50.139: S 744438579:744438579(0) win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:09.871903 10.0.1.50.139 > 192.168.2.75.4241: R 0:0(0) ack 744438580 win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:10.374629 192.168.2.75.4240 > 10.0.1.50.445: S 2252163370:2252163370(0) win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:10.374705 10.0.1.50.445 > 192.168.2.75.4240: R 0:0(0) ack 2252163371 win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:10.374889 192.168.2.75.4241 > 10.0.1.50.139: S 744438579:744438579(0) win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:10.374950 10.0.1.50.139 > 192.168.2.75.4241: R 0:0(0) ack 744438580 win 65535 <mss 1260,nop,wscale 1,nop,nop,timestamp[|tcp]>
19:14:10.376491 192.168.2.75.137 > 10.0.1.50.137:  udp 50
19:14:11.875488 192.168.2.75.137 > 10.0.1.50.137:  udp 50
19:14:13.375697 192.168.2.75.137 > 10.0.1.50.137:  udp 50

I also ran a wireshark trace on the 10.0.1.50 server, I have attached the file but it still doesn't work.

Can anyone give me ideas what I am missing.

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
Kureli Sankar Thu, 03/04/2010 - 18:07

So, if this works with another server in the DMZ and if you have the translation and permission exactly as the working one then, it has to be something wrong with 10.0.1.50 server in the DMZ.

It sends a reset for tcp 445, 139 and just doesn't respond for 137.  Pls. investigate the server.

Will the server not respond to anyone besides the hosts that belong to its own subnet? That is what it looks like.

-KS

AnujPratap Thu, 03/04/2010 - 21:20

If my understanding is correct you want access to 10.0.1.5 (at DMZ) with port 445 from 192.168.2.75 (from Inside).

Kindly check 1st is telnet is happening or not on DMZ server (10.0.1.5) itself or not with port 445.

and as per the capture result there is no any hits to 10.0.1.5 from 192.168.2.75. Please check 1st this also what exactly user is try to access from 192.168.2.75 system.

Anuj Pratap

Kureli Sankar Fri, 03/05/2010 - 06:06

If my previous guess is correct, try to translate the inside host to look like a DMZ 10.x.x.x ip address and see if it can establish a connection.

-KS

Actions

This Discussion