Quantcast
Channel: Forefront TMG and ISA Server forum
Viewing all articles
Browse latest Browse all 3822

Publishing Echange EDGE via TMG

$
0
0
Greetings, community!

We have that infrastructure: 



Each EDGE have: 

As a gateway Front-End DMZ NLB VIP (172.16.0.20). 

Manual static route to the Internal through the Internal Back-End DMZ NLB VIP (172.16.0.100). 

Each DMZ TMG servers have forwarding SMTP traffic rules: 

If the SMTP came to Provider1_IP1 or Provider2_IP1, then redirect all on EDGE-01, saving the source IP 

If the SMTP came to Provider1_IP2 or Provider2_IP2, then redirect all on EDGE-02, saving the source IP 

Also each DMZ TMG have 2 network rules: 

If the request is from the EDGE-01 goes to the External, then NAT traffic through Provider1_IP1 or Provider2_IP1 

If the request is from the EDGE-02 goes to the External, then NAT traffic through Provider1_IP2 or Provider2_IP2 

ISP is enabled on the DMZ TMG for these two providers. 

Actually, the problem: 

Connectivity on 25 port outside only go to one of EDGE servers. In this case, the logs on the DMZ TMG shows that the incoming request "fell off" times out after 21 seconds: 

Failed Connection Attempt DMZ-02 03.09.2014 14:11:46 
Log type: Firewall service 
Status: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond. 
Rule: Publish SMTP to EDGE-02 
Source: External (184.72.226.23:53214) 
Destination: Internal (172.16.0.22:25) 
Protocol: SMTP Server 
Additional information 
Number of bytes sent: 0 Number of bytes received: 0 
Processing time: 21094ms Original Client IP: 184.72.226.23 

But connections to the second server, to any of its two external IP, is connected correctly. 

If I choose SMTP publishing rules instead of saving the source IP address to replace with the IP address of DMZ TMG servers, then all SMTP requests properly reach all 4 my EDGEs IPs. 

However, it's bad solution for me because of Anti-Spam, which needs an IP source to test it (SPF, MX, PTR, Greylisting, etc.) 

Question: What could be the problem? 


I thought that it was problem with routing... For example, EDGE does not know through which server it came to the request and sends the response to VIP DMZ servers, and then triggered by NLB, which throws these packages on the other DMZ-server. Fixed  with a network rule that makes DMZ TMG NAT requests from EDGEs correctly. 

And Wireshark shows that the incoming packet arrived correctly, without errors, but answer-packet with some error: 

Header checksum: 0x0000 [incorrect, should be 0x4f09 (may be caused by "IP checksum offload"?)] 

[GOOD: False] 

[BAD: True] 

Expert Info (Error / Checksum): Bad checksum 

Message: Bad checksum 

Severity level: Error 

Group: Checksum 

Source: 172.16.0.22 (172.16.0.22) 

Destination: 184.72.226.23 (184.72.226.23)

Viewing all articles
Browse latest Browse all 3822

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>