VPN Tunnel, but destination has end to end firewall

Can he just save the report to a file and pull it down to his PC and then print it?
You should be able to set up a printer port on the server to get to that printer by the IP of the tunneled device.

No, the company needs this to be pretty transparent. Connect to server, run job, print report. Report needs to be printed at client's end

How does the printer know which path and port to take back to the client's printer, seeing that this traffic would be new traffic intended for the tunnel?

You should be able to do an add printer as network attached to that remote PC's IP address. You are going to have a route to his site through the tunnel so you should be able to get to it.

Rick, no offense but how exactly do you do this with ISA and a PIX?

In the add printer setup you would have a port number to use and on the firewalls you would have to allow that port through.

Yes, but this is a back to back firewall scenario, and it's not just 2 pixs, it's an ISA 2004.

Shouldn't you just be able to use whatever rules are already in there for this PC as a model and set it up to also allow the printer port and the same address?

New client, new server, new rules.

Not sure that either of us is communicating this well enough.

Here's what I have

client's printer --- client's PC --- client's router---internet---our router---our pix---our isa---our server

the client establishes a secure connection via a vpn tunnel all the way though to the server via a telnet session. He then processes a command, and issues a print request.

This server would then have to print to his printer attached to his PC. For that, I think, a new rule is required on both the isa and the pix, stating that the print job has to be able to traverse through the isa and then the pix via the vpn tunnel.

Is there a solution out there for something like this? A manual, somebody's solution, anything? I need to set this up today.

I thought you said he's done this multiple times which implies the rules to get to and from his PC are already in place. In that case you should just need to open up the port used for printing to the same device.


vpn-ptr.bmp

I'm not sure, but you guys might be "wondering around and around".   You asked the key question in your original post and it doesn't look like it was really noticed (no offence to anyone).

You asked:
What I'm wondering about is the barricade which is the ISA 2004. I would like to know how do I configure both the PIX and the ISA to play well with each other, in terms of packets originating from and destined for the client's side? How do packets behave when dropped on this side of the tunnel on the inside of the PIX?

Exactly!?!  What happens to those packet dumped into space between the PIX and ISA?  They are stuck there and helpless,...it is that simple.

You do not terminate the VPN Tunnel at  the PIX.  You terminate the Tunnel at the ISA.  This has to be done by setting up a IPSec based Site-to-Site VPN Tunnel between the other person's Firewall and your ISA.   As far as you PIx is concerned all it needs to to enable VPN Pass-through (or whatever name Cisco has for the function) so that the Tunnel is pass unmolested through the PIX to the ISA where it then terminates.

If you do not do this then on the ISA you will need to change the Network Relationship from "NAT" to "routed".  This lowers security,...but it is "doable".

In either case the ISA will still control the traffic passing accross with normal outbound Access Rules (yes, outbound).  The only different would be:

1. If the Tunnel terminates at the ISA then the Access RUles would be:
From: Internal,<remote network definition>      To: Internal,<remote network definition>
2.If you did it by changing the Network Relationship then the Rule would be based on:
From: Internal,<IP Range of remote network>      To: Internal,<IP Range of remote network>

Finally!

Thank you for your comment, but is this doable with an ISA2004 & if so, could you point me to a solution/document on the web outlining the steps?

Thank you so much.

Ps. if I route the packets from the pix to the ISA, would they now be not helpless?

Ps. if I route the packets from the pix to the ISA, would they now be not helpless?

Define "route"?  Routing is what routers do.  Where's the router?...There is none.     Routing happens between subnets,...not between Hosts. When the Tunnel terminates on the PIX the packets are just "dumped" into the IP Subnet between the PIX and ISA,...there is no routing happening there.  This IP Segment between the two firewalls is called a "Back-to-Back DMZ".

I gave two completely different options. I can't tell you how to do it unless I know what it is you want to do.

ok, so is this doable with an ISA2004 ?

I think I found something

http://technet.microsoft.com/en-us/library/cc302442.aspx

I need to know which of the two methods I suggested that you want to do.

option 1: tunnel terminates at the ISA

And, all I would have the PIX do is VPN-passthough ? Nice, me likey!

Yes,...the PIX only does the VPN Pass through.  From that point the PIX is invisible to the process.

Then you are looking at this:

Configuring IPSec Site-to-Site Connections Between ISA Server 2004 and Third-Party Gateways
http://technet.microsoft.com/en-us/library/cc302468(loband).aspx
http://www.microsoft.com/technet/prodtechnol/isa/2004/plan/sitetositeipsec.mspx

The guy on the other end with the Cisco product is going to have to know what he is doing on his end.

coming back to Ps. if I route the packets from the pix to the ISA, would they now be not helpless?

Define "route"?  

what would the command on the pix:
route inside a.b.c.d 255.255.255.0 w.x.y.z 1

do? shouldn't it route/hand off the packets destined for a.b.c.d to the external interface of the isa (w.x.y.z)?

what would the command on the pix:route inside a.b.c.d 255.255.255.0 w.x.y.z 1 do?
shouldn't it route/hand off the packets destined for a.b.c.d to the external interface of the isa (w.x.y.z)?

Impossible.  It would not do anything.  The ISA is a firewall,...whatever is behind the ISA Firewall is hidden/protected,...the PIX has no concept or knowledge of what exists behind the ISA.  Hence the packets are trapped in "nowhere-land" between the PIX and the ISA.
The PIX sees the ISA as a meaninless dead-end Host instead of a "router".  Now the static route would cause the PIX to treat the ISA as a LAN Router,...but since it is not a LAN Router,...but is a Firewall,...it won't do anything..

That is why if the Tunnel terminates on the PIX the ISA has to have NAT removed from the Network Relationship between Internal and External so that ISA can then behave as a LAN Router.

You are better off  setting the PIX for VPN-Passthough and terminating the Tunnel at the ISA and forget it.

Humor me here:

on the pix:

access-list outside-access-in extended permit tcp any host A.B.C.D eq 21

where A.B.C.D is one of the external IPs on my PIX

static (inside, outside) A.B.C.D  a.b.c.d netmask 255.255.255.255

where a.b.c.d is the IP of a server inside

route inside w.x.y.0 255.255.255.0 a.b.c.e

where w.x.y.0 is my internal network and a.b.c.e is just another IP on the external of my ISA and w.x.y.0 and a.b.c.0 are different subnets.

On the ISA:

I have rules for redirecting the traffic intended for a.b.c.d to a switch on the inside with a VLAN to the a.b.c.0 network

The above works.

How different is what I'm asking from the above?

just trying to understand

I thought I replied to this,....maybe I forgot to submit it.

If the above "works" as you say,...then you have already reconfigured the Network Relationship between Internal and External on the ISA to be "routed" instead of the default which is "NAT".

If it was NAT it is just flat impossible to "route backwards" through NAT.    Backwards means "from External to Internal".   You can only route forwards through NAT (Internal to External).

It is the way NAT technology is,...it has nothing to do with Microsoft or ISA.

Yes, we have rules that route internal & external traffic

Thank you