OK. I'm just about at my wits end. I've googled around and not found a working solution to my problem. So here it is.
I have a SuSE Linux box behind my ISA Server running SpamAssassin to block SPAM. I have integrated DCC with SpamAssassin to provide more thorough SPAM filtering. So here's the problem. I can't connect with DCC when I am behind the ISA Server firewall.
Now. I googled around and found that I needed the identd service running. So I've installed it. I've also created a packet filter for inbound and outboud UDP port 6277 (I also did this for TCP port 6277 just for good measure). I created a content filter to allow any and all traffic from my SpamAssassin to the dcc external servers.
When none of that worked, I made sure that I had the SOCKS V4 filter enabled and enabled SOCKS on my SpamAssassin. Still no joy in muddville.
So. I ran a network trace on the inboard and outboard adapters on my ISA Server. Now. Here's what I found. I can clearly see my SpamAssassin sending UDP packets to the Inboard adapter on port 6277, but the only UDP packets coming out of the outboard adapter are DNS packets on port 53. And none of them are directed at the IP addresses of the public DCC Servers.
So. I went to my firewall logs. And there are no records indicating blocked packets from my SpamAssassin in IPEXTDnnnn. I also have no records of communication showing up in FWSEXTDnnnn (but that doesn't surprise me because I don't think that secureNAT traffic should show up in that log anyway.)
OK. So. Can anybody help me out here? If I'm not blocking the traffic anywhere (according to my logfiles anyway) then why am I not seeing any traffic on the outboard adapter? Also, has anybody else had this issue and if so, what resolved it?
to allow outbound traffic on UDP port 6277, you must do the following: - make sure the Linux box is configured as a SecureNAT client. - create a new protocol definition for UDP port 6277 send/receive. - allow the new protocol definition in a protocol rule.
You should *never* create IP packet filters to allow internal hosts outbound access. It won't work. So, delete the unnecessary IP packet filters. Also, I highly recommend to apply ISA SP2 too. It fixes a lot of nasty problems.
First, let me say "Thanks", Stefaan for your response.
Unfortunately, that's how I began this journey. I created a protocol definition for UDP port 6277, receive send. Then a protocol rule to allow traffic to a client address set containing the IP address of my Linux box. There was no discernable effect. Since then, I've tried pretty much everything that I can think of to get this problem solved. I have not, however, applied SP2. I may give that a try and see what the results are. Is anyone aware of any issues with SP2? My primary concern here being passive FTP. I had to put the post SP1 hotfix on for that and I'd hate to break it.
But, just for the sake of argument, is there anything unusual about configuring a Linux box as a SecureNAT client? My understanding being that the only requirement to configure a SecureNAT client is to make the ISA Servers internal IP address the Gateway for the client.
Regardless, my primary concern is that I've created a hole large enough to drive a semi-truck through my firewall, and I still don't get any UDP packets on my outboard interface on port 6277. I find that disturbing, to say the least.
Anyway, thanks again for the response and any other assistance you may want to offer will be equally appreciated.
That was the ticket. Chalk it up to dyslexia. I never realized that there was a "send receive" because the "receive send" option appears first in the drop down dialog. It never impinged upon my consciousness that there would be a difference between a UDP Send Receive and a UDP Receive Send.
Can you please clarify a little more about the UDP send receive & receive send.
I understand what you meant in your last message, however you did not continue to explain how this was different from just send or receive when used as singular directions.
Does the "send receive" and "receive send" directions cause the ISA server to hold information about the connection, in the state table, so that the second part of each type of conversation doesn't need to be explicitly expressed as an access rule? Where as a send or receive by themselves would need this??