Michael D. Schleif wrote:
ipsec before nat ???need to know: ipsec v1.91 [A] private networks ================ ^ | v dcd nat/masq ipsec === t-1 | v internet ======== | v cisco router ============ ^ | v [B] dicom black box =============== mixed networks [C] Required: Transfer medical images through one-way ipsec tunnel from [A] to [B]. [D] Required: Cisco router *WILL NOT* route private (rfc 1918) addresses inside network [B]. [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. [H] FreeS/WAN site indicates that this is possible: <http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/HowTo.html#nat_bad> Notice that the links is dead ;< [I] Searching their list archives turns up references to nat-traversal; but, that is not supported in v1.91 -- is it? <http://lists.freeswan.org/pipermail/users/> How have you accomplished this feat?
I haven't, but I'll try to help anyway :)
First of all, while you're on the right track with the above links to the FreeS/WAN documentation, and are correcct about the nat-traversal patches not being applied in the 1.91 version available with Dachstein, I don't think you really need or want this anyway. What the above links are describing is:What pointers can you point out to me? What do you think?
clients -- IPSec GW --- NAT --------IPSec GW -- clients
You do *NOT* appear to have a NAT box between your DCD IPSec box and the internet, and you seem to indicate the Dicom "Black Box" has a public IP, so I'm assuming it's not being NAT'd either.
There are several ways you can go about solving your problem, depending on what configurations are possible on the Diacom. The simplest would be a subnet-subnet IPSec tunnel between [A] and [B]. Note that even with your [A] clients having private networks, the Cisco (and all other intermediate internet routers) *NEVER* see the private IP traffic, as it is encapsulated in the IPSec tunnel...all it will see is IPSec traffic between [A] and [B].
If for whatever reason you cannot setup a subnet-subnet tunnel, you will probably need a host-subnet tunnel. You will have to masquerade or otherwise NAT traffic between the [A] clients and the far end, but you can do this *BEFORE* packets go into the IPSec tunnel:
clients [A] -- IPChains Masq -- IPSec0 ---> Internet
\-------- DCD --------/
You'll probably have to play with your routing and firewall rules to get this working, but it ought to be possible. I know for a fact that packets go through the forward chain prior to hitting the FreeS/WAN virtual IPSec interface, so you should be able to masquerade the private IP clients, but you'll probably have to craft a custom route directing [A] -> [B] traffic to ipsec0, as well as some custom masquerading rules.
Finally, more details on exactly what sort of IPSec configurations you can implement on [B], anything you can tell us about the type of traffic you're trying to tunnel (multiple clients? multiple systems behind the dicom? TCP/UDP traffic to a single port that can be easily masquraded, or a custom protocol that opens lots of random ports between machines?), and anything you've already tested or tried would be helpful in suggesting potential solutions.
--
Charles Steinkuehler
[EMAIL PROTECTED]
-------------------------------------------------------
This sf.net email is sponsored by: See the NEW Palm Tungsten T handheld. Power & Color in a compact size!
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0001en
------------------------------------------------------------------------
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
