1

I have a bizzarre networking problem.

There is a network, a single IP subnet: 192.168.60.0/24.

The network has two Internet-connected firewalls (running ForeFront TMG 2010), 192.168.60.253 (production) and 192.168.60.240 (development); this is a necessity because there are two environment and each of them needs its own Internet-publishing rules; however, for historical reasons, they share the same IP subnet, and this can't be easily changed. Thus, production computers use 192.168.60.253 as their default gateway, while development computers use 192.168.60.240. Everything works, as long as no other networks are involved.

But, of course, there is another network (actually more than one, but let's simplify things)connected to a third NIC on the production firewall, namely 192.168.100.0/24. Computers in this network use that firewall as their default gateway. They can talk with production computers in the main network, and vice-versa.

When computers in the 192.168.100.0/24 network try to talk with development computers in the main network, this doesn't work, because their default gateway (the develompent firewall) doesn't know how to send packets back. This is expected. So I added a permanent static route to the development firewall to tell it "when you need to send a packet to 192.168.100.0/24, send it to 192.168.60.253"; I also defined the network in the networking configuration of TMG end enabled all traffic between the two networks.

Now, the really strange part: pinging between the two networks works, but any other protocol doesn't. HTTP, RDP, SMB... nothing goes through, although routing seems to be working and firewall policies are open for everything.

What's happening, why, and how can I fix it (besides manually adding static routes to each development server, which I'd like to avoid)?

Update:

I examined the traffic logs in the development firewall, and it looks like TCP packets are being dropped because, from that firewall's point of view, they are not related to any open connection. This actually makes sense, because when a connection is started, the initial packet of the TCP handshake goes through the production firewall, while the answer tries to come back through the development firewall... and TMG drops it because it never saw the first packet at all. This also explains why TCP doesn't work while ICMP (and presumably UDP) does.

But still: how can I fix this and make this asymmetric routing work, if it can at all be done?

Massimo
  • 68,714
  • 56
  • 196
  • 319

1 Answers1

0

As I understand...

A packet from 192.168.100.x to a DEV box is routed:

  • into TMG-PROD
  • then to the DEV box

However, packets going from a DEV Box to 192.168.100.x go

  • INTO TMG-DEV
  • then to TMG-PROD
  • then to the 192.168.100.x

Therefore you need to make these routes the same so one suggestions is to add a static route to the DEV box so 192.168.100.x traffic is directed to the TMG-PROD gateway (192.168.60.253)

Phil
  • 3,138
  • 1
  • 21
  • 27
  • You understand correctly, but this is exactly the kind of solution I'd like to avoid, because it requires manually adding a static route (more than one, actually) to *EACH* development server. Can this be made to work in any way while preserving the asymmetric routing, or is it never going to work at all this way? – Massimo Nov 08 '12 at 13:54
  • I dont think it is going to work. We had similar issues when we had two routes to the internet and inbound packets only worked if they went back the "right" way they came in. You could add the routes using group policy if that helps? – Phil Nov 08 '12 at 14:22
  • Yep, pretty sure this won't work - each TMG box needs to have seen the connection setup in order to allow a packet to traverse it. – TristanK Feb 28 '13 at 10:06