[isalist] Re: Mac Connection Problem

http://en.wikipedia.org/wiki/Apple_Filing_Protocol

http://en.wikipedia.org/wiki/Server_Message_Block

From: isalist-bounce@xxxxxxxxxxxxx [mailto:isalist-bounce@xxxxxxxxxxxxx] On 
Behalf Of Rob Moore
Sent: Friday, September 30, 2011 6:32 PM
To: isalist@xxxxxxxxxxxxx
Subject: [isalist] Re: Mac Connection Problem

I've continued to think about this issue and try various other things. Oddly, I 
can do other things from the Macs to the remote servers, such as ping them or 
open an RDP session to them. I see ping and RDP traffic allowed on the TMG 
console. But I can't open the equivalent of an Explorer window to the remote 
servers from a Mac. The TMG server seems to be blocking just that one sort of 
traffic. So how can I tell TMG not to block it? It doesn't SEEM reasonable to 
me (I'm NOT a networking expert) that the problem is the sort of network 
problem Jim described if all kinds of traffic but one can successfully pass.

Thanks,
Rob

From: Rob Moore
Sent: Friday, September 30, 2011 10:28 AM
To: 'isalist@xxxxxxxxxxxxx'
Subject: RE: Mac Connection Problem

If this is true, though, wouldn't it affect all clients at a given site? PCs 
work just fine used from the same locations. It's only the Macs that are 
affected.

I guess your last point would explain why the internal-internal rule didn't do 
anything.  :)

Thanks,
Rob

From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx> 
[mailto:isalist-bounce@xxxxxxxxxxxxx]<mailto:[mailto:isalist-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Jim Harrison
Sent: Friday, September 30, 2011 9:22 AM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Re: Mac Connection Problem

Rob,

Typically, communication failure coupled with those log entries indicates some 
sort of split routing or a response path that is different from the initial 
traffic path.
There are a couple of ways this can occur:

1.       The Linux firewall isn't doing source-NAT and the internal target host 
uses TMG as the default route

2.       The VPN client at the Linux firewall get assigned an IP address that 
is not specified in the target host routing table and the target host uses TMG 
as the default route
In both cases, the initial TCP:SYN will be received by the internal host from 
the Linux FW and its TCP:SYN_ACK response will be sent to TMG; resulting in 
traffic rejection and the log entries you see.

TMG is a stateful firewall and as such, will reject "first seen" TCP traffic 
that fails to abide by RFC-793.

BTW, I hope your "internal-internal" rule is only for testing, as it's 
generally non-functional. Unless TMG is actually separating different subnet 
with individual NICS and both networks have been defined as "internal" to TMG, 
this is a wasted rule.


From: isalist-bounce@xxxxxxxxxxxxx<mailto:isalist-bounce@xxxxxxxxxxxxx> 
[mailto:isalist-bounce@xxxxxxxxxxxxx]<mailto:[mailto:isalist-bounce@xxxxxxxxxxxxx]>
 On Behalf Of Rob Moore
Sent: Thursday, September 29, 2011 8:51 AM
To: isalist@xxxxxxxxxxxxx<mailto:isalist@xxxxxxxxxxxxx>
Subject: [isalist] Mac Connection Problem

Hello Everyone-

I'm using TMG Standard standalone running on Windows 2008 R2 SP1.

We're a mostly Windows organization, though since our new CEO is a Mac-o-phile, 
Macs are becoming more common. Today I found a problem. First let me give you 
some background. Our headquarters is here in Philadelphia. We have 30 remote 
offices, each with a Linux-based firewall that also is a VPN endpoint. There is 
another Linux-based firewall on our network here that all the remote ones VPN 
to. (It's not ideal, but it works and is more affordable for us-a 
non-profit-than what we'd like to have: a bunch of TMG boxes.)

Anyway, Macs here in Philly can connect to our local Windows (2003 or 
2008)-based servers without issue. But when we try to connect a Mac here in 
Philly to a remote Windows server share (the traffic traveling over our 
Linux-based VPN), our TMG server appears to be blocking the traffic. (FWIW, our 
Windows-based clients can connect to those remote servers without issue.) Also, 
if a remote Mac connects to our VPN (PPTP, to a server here in Philly), they 
also can't connect to our remote servers.

The Macs in question are running the latest Mac OSX (10.7.1).

The remote networks are defined on the TMG server as part of the Internal 
network.

There is a TMG rule allowing internal-to-internal traffic (at least I think 
that's what it's doing). The rule is Allow; All Outbound Traffic; From: 
Internal, Local Host; To: Internal, Local Host; All Users. It doesn't seem to 
be applied here, though, based on the error message.

I tried creating a specific rule just for this traffic, and put it at the top 
of the rules (just below my "Block Slammer" rule). That rule is Allow; 
Microsoft CIFS (TCP) and NetBios Session; From Internal, Local Host; To: 
Internal, Local Host; All Users. I get the same error as above, though, 
indicating no rule is applied.

Anyway, we get a lot of these two errors coming through the TMG console when 
the Mac is trying to connect:
Client IP

Destination IP

Destination Port

Protocol

Action

Overridden Rule

NIS Scan Result

NIS Signature

NIS Application Protocol

Rule

Result Code

HTTP Status Code

Client Username

Source Network

Destination Network

172.17.201.39

192.168.9.2

445

Microsoft CIFS (TCP)

Denied Connection

-

None - see Result Code

0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED

Internal

Internal

172.17.201.39

192.168.9.2

139

NetBios Session

Denied Connection

-

None - see Result Code

0xc0040017 FWX_E_TCP_NOT_SYN_PACKET_DROPPED

Internal

Internal


Any help with what's going on? How can I stop TMG from blocking the Microsoft 
CIFS and NetBios protocols over this internal connection? How did I incorrectly 
configure my rule?

Thanks,
Rob

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Rob Moore
Network Manager
215-241-7870
Helpdesk: 800-500-AFSC

Other related posts: