Improve company productivity with a Business Account.Sign Up

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 796
  • Last Modified:

Forefront TMG Routing Issue

We have MS Forefront TMG installed as a back end firewall behind a Cisco ASA connected to a dedicated NIC.  There is a vendor connection being terminated by their device (Cisco 2800 series router) and is handed off to our TMG on a dedicated NIC.  This vendor connection has been in use for over a year now successfully.  Our production network is connected to a separate dedicated NIC on the TMG.

Remote Device<===>Remote ASA<===>Local ASA<===>Cisco 3900 Router<===>Layer 2 Switch<===>Forefront TMG<===>Vendor Router<===>Vendor Network
                            ^
                           ||
                            v
                Production Network

We have added another location across a VPN tunnel terminated by the ASA.  We are attempting to get the new remote location to talk successfully to the vendor's network and are having issues.
We have added the new locations subnet to the 'Internal' TMG network & to the appropriate existing firewall policies.
When we are watching live logging on the TMG server we can see successful outbound connections to the vendors network sourced from the new remote network, but the return traffic from the vendors network is being denied as a spoofing attack.
0
sovran
Asked:
sovran
  • 2
1 Solution
 
Keith AlabasterEnterprise ArchitectCommented:
Run the best practice analyser first to get a picture of the addresses TMG believes are being spoofed.

Spoofing errors are of two kinds - real,,, in which case it's a BIG problem or a simple configuration error where specific IP traffic is being identified coming into one TMG network entity definition but TMG is configured to expect those IP addresses to arrive at a different network network entity definition.

The main config error for spoofing again comes in two types.

The first being that the remote site has overlapping subnets with yours which is a no-no of course and second that the new network entity created for the VPN has not covered all of the ip addresses in the range including the network id and the broadcast address. For example, if the remote subnet was 192.168.10.0/24 then the network entity would need to be defined as 192.168.10.0 - 192.168.10.255.
0
 
sovranAuthor Commented:
Turned out the vendor on the remote side configured two of their devices to communicate on the same port to our network.  So it was real, just not something that we could fix.  Once they made the change we were up and running.
0
 
sovranAuthor Commented:
Solved
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now