Various comments inline...initial network diagram repeated (slightly modified) for handy reference.
NOTE: New Labels for DCD and Cisco
Michael D. Schleif wrote:
ipsec before nat ???
I'm thinking NAT before IPSec, as you've got it drawn.
OK, this means an IPSec tunnel between [DCD] and [CR], allowing [A] to access [B]need to know: ipsec v1.91 [A] private networks ================ ^ | v [DCD] dcd nat/masq ipsec === t-1 | v internet ======== | v [CR] cisco router ============ ^ | v [B] dicom black box =============== mixed networks [C] Required: Transfer medical images through one-way ipsec tunnel from [A] to [B].
OK, I actually *LIKE* using private IP's for VPN links, as it makes it very easy to filter external access (making sure it's impossible for anyone not on an internal or VPN network to access resources), but we've all got our pet peeves. Since [A] is private IP space, this means you need to MASQ traffic on [DCD] prior to it's entering the ipsec tunnel.[D] Required: Cisco router *WILL NOT* route private (rfc 1918) addresses inside network [B].
You should be able to setup an ipsec link using IP's from [Z] without trouble...actually, this is easier than using [Y].[E] T1 on side [A] has one (1) /32 network [Z]. [F] ISP on side [A] also routes one (1) public /28 network [Y] that is _different_ from T1 network. Therefore, ip alias and dmz are options. [G] Manager of [B] wants to see [Z] at [B]; but, if requirements are now exhaustive, then [Y] should also be acceptable.
>> Also, it *IS* possible to do Masquerading prior to the IPSec tunnel:
>> http://www.freeswan.org/freeswan_trees/freeswan-1.99/doc/firewall.html#NAT
>
> Unfortunately, Andre wants us to do "ipsec before nat" or "nat between
> gateways".
>
> By-the-by, the reason that the /21 subnet is commented out is this
> link's suggestion: "omit the leftsubnet= parameter".
Of course. If you think about it, the easy way to set this up would be to create a subnet-subnet tunnel between [DCD] and [CR] linking the [A] networks with the [B] networks. However, since the [A] networks consist of those nasty Private IP's (which must have cooties or something), this solution is not administratevely permitted.
That leaves the option of masquerading the [A] networks behind the public IP of [DCD], prior to sending packets through the IPSec tunnel. Since the tunnel traffic now consists entirely of traffic between [DCD]'s public IP and the [B] network(s), this is a host-subnet tunnel, and does *NOT* require a leftsubnet parameter, assuming [A] and [DCD] are "left" with [B] and [CR] being "right".
>> Finally, more details on exactly what sort of IPSec configurations
>> you can implement on [B],
>
> This is all that I can get out of Andre:
>
> crypto isakmp policy 5
> encr 3des
> hash md5
> authentication pre-share
> group 5
> !
> crypto isakmp policy 10
> encr 3des
> hash md5
> authentication pre-share
> !
> crypto isakmp policy 15
> encr 3des
> hash md5
> authentication pre-share
> group 2
> crypto isakmp key _secret_preshared_key_ address _our_T1_address_
> crypto ipsec transform-set vpn-3des esp-3des esp-md5-hmac
> !
> crypto dynamic-map DYN-VPN 10
> set transform-set vpn-3des vpn-des
> crypto map VPN local-address FastEthernet0/0
> crypto map VPN 10 ipsec-isakmp dynamic DYN-VPN
I'm not much of a Cisco IPSec expert, but as long as this is a host-subnet tunnel, you should be OK. At least the cisco manuals are online, so you can find out what everything means. I'd start by figuring out exactly what "crypto map VPN local-address FastEthernet0/0" means...that looks like the cisco-side network definition. Off-hand, I'd say it looks like it specifies a subnet rather than a single IP, but that's strictly a WAG.
My suggestion for dealing with the far end administrator would be to nod along politely when he tells you how you have to configure your end, and go through whatever motions are required to get him to setup a host-subnet tunnel between [DCD] (your local host) and [CR]/[B] (remote host/subnet). "Sure...we're NATing just like you said we needed to."
Also note that ipsec *DOES* get it's packets directly from the input chain (so your remote admin is at least partly correct), but that's on *RECEPTION* of external traffic, not when sending packets. Regardless, this guy doesn't sound like someone you want to confuse with the facts, so just smile and nod...you've got enough problems already. :)
Once you get a [DCD]host-[B]subnet tunnel up, you can play with packet masquerading rules and route table entries to get traffic flowing properly (assuming, of course, your applications masquerade nicely).
If you really run into a brick wall with the remote administrator, I can probably help setup a test network to do proof of concept stuff, and figure out the configuration snafus. I did just donate my LRP test boxes to the KCLUG cluster project, but I can still scrape enough hardware together to do a few tests... :)
Oh...and this would still be light-years easier if you could simply make an [A]subnet-[B]subnet IPSec tunnel, but then Private IP's would be invading the remote network, possibly tripping various alarms or IDS monitors or something...I'd hope there's at least a valid reason this isn't being considered as a possible option.
One side benifit of the host-subnet + masquerading configuration:
Your local [A] networks will be isolated from the folks on [B] by masquerading rules. From the sound of it, this might be a Very Good Thing <TM>. ;-)
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
------------------------------------------------------------------------
leaf-user mailing list: [EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/leaf-user
SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
