Charles, thank you, for your participation. Much ado inline . . .
The most difficult part of this project is that the technician at [B]
is difficult, inflexible and paranoid -- these are medical (read,
hiipa) images to be transferred.
Everything [B]-side of the cisco is a black box -- we cannot directly
see anything going on there. Andre speaks with a heavy accent and
often does not adequately describe what is going on. Besides that, all
of his other clients are using cisco or equally overpriced solutions.
If you saw Thursday's posts, he insisted that we send in transport
mode; until I proved to him that that is not possible in a gw-gw
configuration.
All along, except with erroneous transport attempts, we successfully
achieve SA:
"go-net" #1: STATE_MAIN_I4: ISAKMP SA established
With tcpdump, we can see ping, ftp & telnet packets go through the
tunnel without any errors in auth.log nor kern.log.
What we cannot do is get any answer -- *NOTHING* comes back !?!?
Andre insists that we need to nat/masq *AFTER* the ipsec transform --
hence my questions regarding:
nat between gateways
ipsec before nat
Michael D. Schleif wrote:
<snip />
> > [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 :)
>
> > What pointers can you point out to me?
> >
> > What do you think?
>
> 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:
>
> 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.
Yes, you are correct, up to the dicom box[en] having public ip.
Andre says that he cannot allow routing of _any_ rfc 1918 addresses,
since he cannot risk two (2) clients using same address. In the next
breath, he stated that his internal networks are, indeed, rfc 1918.
He says that he expects to see our gw address connect to his gw *AND*
he expects to see _only_ our gw address coming out of the tunnel ?!?!
We removed leftsubnet=, according to:
<http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/HowTo.html#nat_ok>
Now, he says that he sees packets with the expected address (where?);
but, something about the address is mangled when it comes out of the
tunnel ???
> 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].
This -- except for the ridiculous transport detour -- is what we are
doing.
> 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.
This is where I am stuck. I think that I know what you are saying;
but, translating that into specific tasks is losing me . . .
> I know for a fact that
> packets go through the forward chain prior to hitting the FreeS/WAN
> virtual IPSec interface,
We had a long argument about that Friday afternoon. Andre insists that
ipsec gets the packets from the input chain; that the packets _never_
get to the forwarding chain. In fact, he was telling me to add MASQ
rules to input chain (man ipchains(8): "MASQ is only legal for the
forward and user defined chains ...")
> 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.
Are you saying to add something ipsec0-specific to this?
# ipchains -nvL --line-numbers | grep MASQ
8 151 23639 MASQ udp ------ 0xFF 0x00 * 192.168.12.253 0.0.0.0/0 161 -> *
9 119 18204 MASQ udp ------ 0xFF 0x00 * 192.168.12.252 0.0.0.0/0 161 -> *
10 108 13500 MASQ udp ------ 0xFF 0x00 * 192.168.11.10 0.0.0.0/0 161 -> *
11 0 0 MASQ tcp ------ 0xFF 0x00 * 192.168.12.89 0.0.0.0/0 5631 -> *
12 0 0 MASQ udp ------ 0xFF 0x00 * 192.168.12.89 0.0.0.0/0 5632 -> *
13 222K 18M MASQ tcp ------ 0xFF 0x00 * 192.168.11.10 0.0.0.0/0 5631 -> *
14 0 0 MASQ udp ------ 0xFF 0x00 * 192.168.11.10 0.0.0.0/0 5632 -> *
15 86773 74M MASQ all ------ 0xFF 0x00 wan1 192.168.11.0/24 0.0.0.0/0 n/a
16 2717 2443K MASQ all ------ 0xFF 0x00 wan1 192.168.12.0/24 0.0.0.0/0 n/a
17 451K 420M MASQ all ------ 0xFF 0x00 wan1 192.168.13.0/24 0.0.0.0/0 n/a
> 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
> anything you can tell us about the type of traffic
> you're trying to tunnel (multiple clients?
Yes, there are now five (5) clients behind [A], on three (3) different
private networks; and, this number is expected to increase in the next
year.
> multiple systems behind the dicom?
Yes, but as black box, we are privy to no specific numbers.
> TCP/UDP traffic to a single port that can be easily masquraded,
Yes, there are a small handful of tcp ports targeted in [B].
> or a custom protocol that opens lots of random ports between machines?),
<cagey>No, this is not my current understanding.</cagey>
> and anything you've already tested or tried would be helpful in
> suggesting potential solutions.
ipsec.conf (abridged, removing only comments):
==========
config setup
### forwardcontrol=no
interfaces=%defaultroute
## klipsdebug=all
klipsdebug=none
## plutodebug=all
plutodebug=none
plutoload=%search
plutostart=%search
uniqueids=yes
conn %default
authby=rsasig
auto=start
# keyexchange=ike
keyingtries=0
# keylife=8h
left=%defaultroute
leftfirewall=yes
[EMAIL PROTECTED]
leftrsasigkey=_secret_key_for_other_vpns_
### leftsubnet=192.168.11.0/24
### leftsubnet=192.168.8.0/21
include ipsec/go-net.conf
go-net.conf
===========
conn go-net
### auth=ah
authby=secret
### esp=3des-md5-96
### keyexchange=ike
### leftsubnet=
### pfs=no
right=204.235.103.2
rightid=204.235.103.2
rightsubnet=204.235.101.128/28
### spibase=0x200
### type=transport
--
Best Regards,
mds
mds resource
888.250.3987
Dare to fix things before they break . . .
Our capacity for understanding is inversely proportional to how much we think we know.
The more I know, the more I know I don't know . . .
-------------------------------------------------------
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
