Welcome to ISAserver.org

Site to Site VPN terminating in front of ISA 2004 - two nics

Users viewing this topic: none

Logged in as: Guest

Printable Version

All Forums >> [ISA Server 2004 Firewall] >> Network Infrastructure >> Site to Site VPN terminating in front of ISA 2004 - two nics

Page: [1]

Message

<< Older Topic Newer Topic >>

Site to Site VPN terminating in front of ISA 2004 - two... - 13.Nov.2007 4:40:44 AM

tlfreest

Posts: 1
Joined: 13.Nov.2007
Status: offline

Greetings fellow propeller-heads,

I have been a grateful reader of the posts both by the admin population and especially Tom Shinder in this forum for quite some time. There has been many an issue solved by reading the posts herein.

I recently have solved, or so I believe, the dilemma that arises if you have a hardware firewall/VPN device in front of your ISA 2004 server (two nics), and you need to create a site-to-site VPN tunnel from the hardware firewall/VPN device to a resource on the internal network of the ISA 2004 server. So in other words, we are passing VPN/DMZ traffic external to the ISA server back and forth between an internal resource and the remote network of the VPN tunnel.

This post is both to describe how this is working for us, and to solicit any advice/comment from the masses and Tom S. as to any inherent network exposure I may have missed during my bleary-eyed, late night MT Dew brainstorming sessions. I manage this network remotely in the evenings and weekends, my day job is an IT Specialist for another company. I operate with this entity as a consultant under a maintenance contract.

Now before I go over how I was able to make this work, I know everyone, including Tom may be saying, "WHY would anyone have the WAN side of their network configured this way?� The powers-that-be of this entity decided that they wanted to have a two-layer, DMZ approach before I arrived on the scene. I wasn't able to effect a change in the topology, so as we all are forced to sometimes; I went after a solution with the network as it sits. They are not able to secure another public IP with their rural DSL provider at this time. If that had been allowable then I would have placed a third NIC in their ISA server and used it exclusively as the site-to-site tunnel endpoint.

If the following solution hadn't worked my next idea was going to be to still add a third NIC and create a separate DMZ between it and the Watchguard's "Optional" DMZ interface. Then I was going to add a network to their ISA server and routes to the Watchguard and use that topology to route all site-to-site VPN traffic through the ISA server, still using the single public IP and the Watchguard as the VPN gateway.

Current solution in place (and a bit of background):

This networks belongs to a small, rural hospital that sends its CT/Ultrasound and X-ray images to the larger hospitals in the area to be read by the on-call radiologist.

In the past these images either went across a T-1 to their partner hospital, or to web-accessible end-points with public IP's that the sending app connected to directly.

Recently another hospital wanted to offer these services as well, but they needed to have a site-to-site VPN tunnel in place to connect the small hospital's sending app with their PACS system. The small hospital uses a Watchguard x55e on their DSL connection, and then it is connected on its internal interface to one of the two nics in their SBS 2003/ISA 2004 server. The larger hospital is using a Cisco PIX/ASA appliance to provide its VPN tunnels.

I set up the VPN tunnel between the Watchguard device and the Cisco PIX in a normal fashion, setting the internal IP of the image-sending PC as a Phase 2 tunnel member, as well as the large hospitals two PACS locations. I also added a route in the table of the Watchguard pointing traffic headed for the internal IP of the image-sending PC's IP to the IP of the ISA server's external NIC.

Then in ISA I added a new Network as a "Route" relationship between the internal IP of the image-sending PC and the two PACS IP's at the larger hospital. I mirrored the "From" and "To" settings so that each of the endpoints appeared in both.

Next I added an access rule designating that DICOM (port 104) and ping traffic from the private PACS IP's to the internal image-sending PC IP and vice versa was allowed. I included the IP of the internal side of the Watchguard (basically one side of the DMZ

Then today, we fired up some ping traffic, waited for the tunnel to come up, and successfully sent an image from the small hospital's image-sending PC to the larger hospital's PACS system.

So there you have it. Please let me know if you have any comments and/or questions regarding any part of this particular solution.

Thanks!