Video Screencast Help
Symantec Appoints Michael A. Brown CEO. Learn more.

Symantec Mail Gateway - Behind TMG

Created: 31 Mar 2013 • Updated: 01 Apr 2013 | 12 comments
Rui Ribeiro's picture
This issue has been solved. See solution.

Gents

Software in this set up

1 x Forefront TMG 2010

2 x Exchange CAS/HUB in NLB set up

1 x Mail Gateway 10.0.2 Virtual Edition

Just finished an implementation of a Mail Gateway Appliance, i have set up the appliance behind a Microsoft TMG 2010, Mail arrives from outside, pass thru TMG then gets filtered on the Mail Appliance then it delivers it to my Client Access Array.

All works well but then after these past 3 days i have noticed a large amount of blocked connections attemps made by the forefront to the Mail Appliance i think, this is what it is on the diagnostics:

The FULL log is attached.

Any help would be appriciated.

2013 Mar 31 01:54:32 (notice) stunnel: LOG5[19264:3086904208]: Protocol negotiations succeeded
2013 Mar 31 01:54:33 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=3, /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
2013 Mar 31 01:54:33 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=2, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2013 Mar 31 01:54:33 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=1, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
2013 Mar 31 01:54:33 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=0, /C=US/ST=California/L=Mountain View/O=Symantec Corporation/OU=Messaging and Web Security/CN=SWUPDATE.BRIGHTMAIL.COM
2013 Mar 31 01:54:34 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=3, /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
2013 Mar 31 01:54:34 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=2, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5
2013 Mar 31 01:54:34 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=1, /C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at https://www.verisign.com/rpa (c)10/CN=VeriSign Class 3 International Server CA - G3
2013 Mar 31 01:54:34 (notice) stunnel: LOG5[19264:3086904208]: Certificate accepted: depth=0, /C=US/ST=California/L=Mountain View/O=Symantec Corporation/OU=Messaging and Web Security/CN=SWUPDATE.BRIGHTMAIL.COM
2013 Mar 31 01:54:34 (notice) stunnel: LOG5[19264:3086904208]: Connection closed: 404 bytes sent to SSL, 498 bytes sent to socket
2013 Mar 31 01:57:35 (notice) syslog-ng[1884]: STATS: dropped 0
2013 Mar 31 02:01:28 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https accepted connection from 127.0.0.1:54456
2013 Mar 31 02:01:28 (notice) stunnel: LOG5[19264:3086904208]: connect_blocking: connected 172.31.255.251:8080
2013 Mar 31 02:01:28 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https connected remote server from 172.31.255.233:64091
2013 Mar 31 02:01:28 (notice) stunnel: LOG5[19264:3086904208]: Negotiations for connect (client side) started
2013 Mar 31 02:01:41 (err) stunnel: LOG3[19264:3086904208]: CONNECT request rejected
2013 Mar 31 02:01:41 (notice) stunnel: LOG5[19264:3086904208]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2013 Mar 31 02:01:41 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https accepted connection from 127.0.0.1:54459
2013 Mar 31 02:01:41 (notice) stunnel: LOG5[19264:3086904208]: connect_blocking: connected 172.31.255.251:8080
2013 Mar 31 02:01:41 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https connected remote server from 172.31.255.233:64094
2013 Mar 31 02:01:41 (notice) stunnel: LOG5[19264:3086904208]: Negotiations for connect (client side) started
2013 Mar 31 02:02:05 (err) stunnel: LOG3[19264:3086904208]: CONNECT request rejected
2013 Mar 31 02:02:05 (notice) stunnel: LOG5[19264:3086904208]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2013 Mar 31 02:02:05 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https accepted connection from 127.0.0.1:54462
2013 Mar 31 02:02:05 (notice) stunnel: LOG5[19264:3086904208]: connect_blocking: connected 172.31.255.251:8080
2013 Mar 31 02:02:05 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https connected remote server from 172.31.255.233:64097
2013 Mar 31 02:02:05 (notice) stunnel: LOG5[19264:3086904208]: Negotiations for connect (client side) started
2013 Mar 31 02:02:29 (err) stunnel: LOG3[19264:3086904208]: CONNECT request rejected
2013 Mar 31 02:02:29 (notice) stunnel: LOG5[19264:3086904208]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2013 Mar 31 02:02:29 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https accepted connection from 127.0.0.1:54465
2013 Mar 31 02:02:29 (notice) stunnel: LOG5[19264:3086904208]: connect_blocking: connected 172.31.255.251:8080
2013 Mar 31 02:02:29 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https connected remote server from 172.31.255.233:64100
2013 Mar 31 02:02:29 (notice) stunnel: LOG5[19264:3086904208]: Negotiations for connect (client side) started
2013 Mar 31 02:02:53 (err) stunnel: LOG3[19264:3086904208]: CONNECT request rejected
2013 Mar 31 02:02:53 (notice) stunnel: LOG5[19264:3086904208]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2013 Mar 31 02:02:53 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https accepted connection from 127.0.0.1:54468
2013 Mar 31 02:02:53 (notice) stunnel: LOG5[19264:3086904208]: connect_blocking: connected 172.31.255.251:8080
2013 Mar 31 02:02:53 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https connected remote server from 172.31.255.233:64103
2013 Mar 31 02:02:53 (notice) stunnel: LOG5[19264:3086904208]: Negotiations for connect (client side) started
2013 Mar 31 02:03:17 (err) stunnel: LOG3[19264:3086904208]: CONNECT request rejected
2013 Mar 31 02:03:17 (notice) stunnel: LOG5[19264:3086904208]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
2013 Mar 31 02:03:17 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https accepted connection from 127.0.0.1:54471
2013 Mar 31 02:03:17 (notice) stunnel: LOG5[19264:3086904208]: connect_blocking: connected 172.31.255.251:8080
2013 Mar 31 02:03:17 (notice) stunnel: LOG5[19264:3086904208]: Service pseudo-https connected remote server from 172.31.255.233:64106
2013 Mar 31 02:03:17 (notice) stunnel: LOG5[19264:3086904208]: Negotiations for connect (client side) started

Operating Systems:

Comments 12 CommentsJump to latest comment

Amir Mahook's picture

Dear Rui,

Make sure you have the following:

  1. From SMG --> Administration --> Host à SMTP --> incoming --> Accept inbound mail connections from all IP addresses and domains should be selected.
  2. From TMG --> Firewall Policy --> open the incoming allowed policy for SMTP that is forwarded to SMG --> make sure you select under "To" tab the options called “Requests appear to come from the original client”

hope this solve your issue

TSE-JDavis's picture

You need to add the IP address of this TMG into the Messaging Gateway's Internal Mail Hosts list so it doesn't think it is some server outside sending it a ton of mail. This list is under Administration->Configuration->scanner name.

Rui Ribeiro's picture

Thank you guys for the responses.

@Amir : It is already configured like that.

@TSE-JDavis : I tought this was it, i configured as you said but still the log and the dashboard keeps on showing a lot of connections been rejected. I have waited about 30min now and the log just keeps on growing.

BTW: The internal mail list has all my IP Addresses from ALL my Exchange server configured on there just in case.

TSE-JDavis's picture

There no need to put the Exchange servers in that list since they are behind the Messaging Gateway. That list is only for mail servers sending INCOMING mail to the Messaging Gateway so it does not throttle the connections with Connection Classification.

What do you see when you perform a Message Audit Log search for messages coming from that IP address and the verdict of rejected?

TSE-JDavis's picture

I didn't noticed before, but the log snippet you pasted here is only showing stunnel rejections. This is the secure tunnel daemon (HTTPS) and nothing to do with mail. Where are you seeing these mail rejections?

Rui Ribeiro's picture

@TSE-JDavis

Spoke to soon, let me observe futher, the amount of connections has decreased considerebly...

I will give mark as answered later in the evening... give another 4 hours to monitor the appliance.

But look better... still have many bad connections around 3 per minute instead of 12

Still need to understadn the amount of BAD connections... :-/

Cheers

Rui Ribeiro's picture

The dashboard itself... and the only log i can see something showing a reject is on messages log... if you scroll down the message log you will see roughtly the same amount of connections been rejected wich reflects with the dashboard.

Am i wrong?

Yes you are it is the HTTPS tunnel... but it is showing on the DASHBOARD have a look at the pic i attached... you will see what i mean.

TSE-JDavis's picture

Looking at the Dashboard picture you sent, it looks like the only reason we are blocking incoming connections is due to Bad Reputation. This is when an IP address is known as a sender of spam or malicious emails.

Rui Ribeiro's picture

But lookin at the reports of bad connections i dont see anything there :-/

Where should i look for information?

TSE-JDavis's picture

You would need to perform a search in the Message Audit Log. I assume that you are wondering which IP addresses are being blocked? What is it that you are looking for exactly?

SOLUTION
Rui Ribeiro's picture

That is correct, the IPs that are being blocked.

Just to let you know after adding the TMG IP to the internal mail host table the dashboard really changed... not sure if this a coincidence... but it really did improve... decrease around 60 connections... it is looking a bit more like i am used too.. :-)

Rui Ribeiro's picture

Nevermind i just found it out... it was a PRTG sensor trying to connec on the port 25, i ran the reject connections report and saw the IP there.

Will close it for now.