how to return web service calls via a different network route?

[Bob]

I'm implementing a file transfer application to transfer confidential files
from our corporate intranet to our web server in the DMZ. I was able to use
WSE 1.0 DIME attachment for this without problem. The WS client is
installed on a server on the intranet, and it calls the WS server on the DMZ
to send files. All is well in development until this is moved into
production. It turned out that we have strict security policies and traffic
can go only in one direction from the intranet to the DMZ but not back, even
on port 443. Since the default WS implementation in ASP.NET uses
HTTP/HTTPS, the HTTP response can't go back to the client so the client
always thinks it failed. Is there a way to do a "fire-and-forget" call, so
the client won't anticipate a resonse? Or getting the response using a
different protocol such as SMTP so the client would receive an email? The
response doesn't contain any real confidential data so it can go to the
internet and come back if has to.

Any other suggestions would be appreciated too.

Thanks
Bob

 

[Guest]

I don't think this is even possible... if an inbound connection is made to a port, the low-level TCP stack needs to be able to send information back (framing, retries, etc.), so if all outbounds packets are dropped, the TCP layer would break

I am surprised you receive the request al all... unless maybe it fits in a single TCP/IP segment)

My assessment is incorrect if your firewall is doing some sort of packet inspection and removing replies with content