Packet returning via different path problem when using TCP

[b.hart]

Currently we a in a peroid of migrating with our WAN from leased line to Frame Relay.

Here is the problem. All VLAN 1 traffic is currently routed via the new FR network for testing. All other VLAN's are routed via the old leased lines. If I ping from VLAN 1 to a remote machine on say VLAN 105 I get a reply. The packet goes over the leased line and returns via the FR WAN. That is to be expected. This ping is UDP. Right?

If I telnet from VLAN 1 to a remote machine on VLAN 1 everything is OK because both the outgoing and incoming packets follow the same paths. With me so far?

If I telnet from VLAN 1 to VLAN 105 on the remote site I cannot get a telnet session. The outgoing packets are going via the FR WAN and the return packets are going over the leased line. Is there a problem with TCP communication where the return path is different to that of the outgoing path?. That is my question.

[svermill]

There are security implementations that check to ensure incoming TCP was "established" by an inside source. I believe that part of being established (aside from the bit being set) is that some stateful information match up. Any PIX experts out there?

[yagnesh.patel]

TCP should not be any problems with having asymmetric routing otherwise internet would die.

[svermill]

Of course TCP knows nothing of the mechanics of the lower layer protocols. So symmetry is not a TCP concept. But I was hoping for a PIX/security expert to comment on how stateful information (such as incoming/outgoing ports) affects permissions for various types of traffic flows.