Hi Tom, I've reproduced the issue with TCPdump running on Windows server in loc (192.168.1.0/24) and remote client (with IP 192.168.200.32). The client with working CIFS is also in loc (192.168.1.0/24). I have not configured a new zone or anything else related to the VPN connection.
Here's the dump from client:
thomas@pc5-desktop:~$ sudo tcpdump -i eth0 -n -s0 host win10 and port 445
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
00:16:15.249437 IP 192.168.200.32.60098 > 192.168.1.123.445: Flags [S],
seq 3478483138, win 29200, options [mss 1460,sackOK,TS val 681979375 ecr
0,nop,wscale 7], length 0
00:16:16.277772 IP 192.168.200.32.60098 > 192.168.1.123.445: Flags [S],
seq 3478483138, win 29200, options [mss 1460,sackOK,TS val 681980404 ecr
0,nop,wscale 7], length 0
00:16:18.293764 IP 192.168.200.32.60098 > 192.168.1.123.445: Flags [S],
seq 3478483138, win 29200, options [mss 1460,sackOK,TS val 681982420 ecr
0,nop,wscale 7], length 0
And this is the dump from Windows server:
c:\Users\thomas\Downloads>windump -D
1.\Device\NPF_{85F60C6D-9764-410D-B8D6-C492F4C80984} (Red Hat)
c:\Users\thomas\Downloads>WinDump.exe -i 1 -n -s 0 port 445
WinDump.exe: listening on \Device\NPF_{85F60C6D-9764-410D-B8D6-C492F4C80984}
00:16:16.277567 IP 192.168.200.32.60098 > 192.168.1.123.445: S
3478483138:3478483138(0) win 29200 <mss 1382,sackOK,timestamp 681979375
0,nop,wscale 7>
00:16:17.299901 IP 192.168.200.32.60098 > 192.168.1.123.445: S
3478483138:3478483138(0) win 29200 <mss 1382,sackOK,timestamp 681980404
0,nop,wscale 7>
00:16:19.315761 IP 192.168.200.32.60098 > 192.168.1.123.445: S
3478483138:3478483138(0) win 29200 <mss 1382,sackOK,timestamp 681982420
0,nop,wscale 7>
I have also reconfigured /etc/shorewall/policy as follows:
#SOURCE DEST POLICY LOG LEVEL BURST:LIMIT
net all DROP info
loc all REJECT warning
fb dmz REJECT warning
fb loc REJECT warning
dmz all REJECT warning
vpn all REJECT warning
$FW all ACCEPT
# THE FOLLOWING POLICY MUST BE LAST
all all REJECT info
What else would be needed for error analysis?
THX
Am 11.02.2018 um 20:31 schrieb Tom Eastep:
> On 02/11/2018 06:19 AM, Thomas wrote:
>> Hi,
>>
>> I have a working Shorewall firewall connection.
>> Just recently I setup a VPN connection between two FRITZ!Box networks
>> <https://en.avm.de/service/fritzbox/fritzbox-7390/knowledge-base/publication/show/5_Setting-up-a-VPN-connection-between-two-FRITZ-Box-networks/>:
>> netA + netB
>> Hereby I can connect to a PC in netB from any PC in netA using SSH.
>> However, I cannot connect to a Windows server in netB from a PC in netA
>> using Samba CIFS.
>>
>> I have created a TCPdump on Windows server when trying to establish
>> connection from client: /tcpdump_cifs_server_failure.txt/
>>
>> And I have created a TCPdump on the Linux client (in netA) when trying
>> to establish connection: /tcpdump_cifs_client.txt/
>>
>> In addition I have created shorewall dump and attached to this email.
>>
>> To verify if the CIFS connection is working, I connected from client in
>> netB to Windows server, and this was successfull. The relevant TCPdump
>> is attached, too: /tcpdump_cifs_server_working.txt/
>>
>> My assumption was that Shorewall is filtering CIFS (port 445), but I'm
>> not sure how to verify this.
>> Is it necessary to define rules for to connect to servers in netB?
> In general, if the applicable Shorewall policy is not ACCEPT, then
> rules must be specified to allow *ANY* traffic to be passed through
> a Shorewall-based firewall.
>
>> Please advise how to proceed here for solving this issue?
> There are a couple of unknowns in this problem report:
>
> a) You don't mention how the client and server relate to the Shorewall
> box. In other words, in which zone is the client and in which zone
> is the server?
>
> b) The tcpdumps didn't specify the -n option, so rather than IP
> addresses, the dumps contain DNS names. Consequently they aren't
> helpful in answering the question in a), and from a troubleshooting
> point of view, they are not helpful.
>
> Your Shorewall configuration has REJECT policies that don't specify a
> log level. There are a large number of connections being rejected, but
> we can't see what those connections are because they are not being
> logged. That is probably not relevant in this case, as the tcpdump in
> tcpdump_cifs_server_failure.txt suggests that the SYN packets are being
> dropped rather than rejected. The packets that the dump shows being
> dropped are broadcast packets, which indicates to me that it is not the
> Shorewall-generated ruleset that is dropping the packets (assuming that
> you tried to connect after the rulset was reset ( 4. Feb 15:07:50 CET
> 2018) and when the Shorewall dump was taken (4. Feb 15:07:49 CET 2018).
>
> -Tom
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> Shorewall-users mailing list
> Shorewall-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/shorewall-users
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________ Shorewall-users mailing list Shorewall-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/shorewall-users
