RE: [fw-wiz] IP migration on "hub" VPN terminus [long]
From: Robert L. Wanamaker (bobw_at_avantsystems.com)
Date: 03/31/04
- Next in thread: Robert L. Wanamaker: "RE: [fw-wiz] IP migration on "hub" VPN terminus [long]"
- Maybe reply: Robert L. Wanamaker: "RE: [fw-wiz] IP migration on "hub" VPN terminus [long]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
To: <firewall-wizards@honor.icsalabs.com> Date: Tue, 30 Mar 2004 19:53:34 -0500
Melson, Paul wrote:
>>
> -----Original Message-----
> (3) add necessary statements for Cisco Secure VPN client to connect
> from any location, and telnet into the remote pix.
> (4) Use the VPN client to directly connect to each PIX, and create a
> separate crypto map entry pointing to the new VPN peer
AFAIK, this can't happen. PIX firewalls won't pass traffic back to
themselves on the same interface. This applies to both 3 and 4. If you're
connected to the PIX via VPN client and connecting to it via Telnet on its
outside interface, you're Telnet connection is almost certainly not
encrypted. Set up SSH or PDM (HTTPS) and restrict access to known
addresses.
<<
You [and Josh] were much too kind in pointing out my oversight on SSH.
However, the trick with the VPN client does indeed work. From a simple
thought experiment, if I have a PC running the VPN client, with a connection
to a PIX that does not permit split-tunneling, and I can then telnet from
that PC to the outside interface of the PIX, encryption _must_ be happening;
by definition, the PC can't be sending unencrypted traffic anywhere, since
split-tunnelling is not permitted. A network analyzer verifies this, btw.
>>
> (5) Split apart the 515's at the hub; run each in standalone mode, one
> connected to the old ISP network, and one connected to the new ISP
> network.
> (6) Cut the tie to the old ISP. Watch all the tunnels get gracefully
> rebuilt on the second 515 with little or no impact to users.
Good luck! :)
> Testing results. I've tested 1, 3, 4 with good results. My only
> weird results are that Cisco's site has numerous e.g.'s of the VPN
> client connecting with DES encryption; however, I can only make it
> work with 3-DES. This is certainly a good excuse for getting the
> client up to current rev, but am I missing something?
The VPN client has a limited number of supported IKE proposals. If you're
using PSK, DES will only work with MD5 and DH Group 2. If you're using RSA
certificates, it's MD5 and DH Group 1. There's a handy IKE Proposal table
here:
http://www.cisco.com/en/US/partner/products/sw/secursw/ps2308/products_a
dministration_guide09186a00800bd991.html#1157757
> Questions. Does this sound feasible? Is there a better way to
> accomplish this cutover?
My advice is that you should plan for problems. If you succeed in upgrading
all 30 506's and cutting over the 515's without incident, you're wasting
your life in networking - you belong at a blackjack table in Vegas. To that
end, get some external modems and console cables to ship out and coordinate
with someone onsite who will be available to plug them in and power cycle
things to reduce downtime when it does happen.
Anyway, I don't know enough about your time constraints, external
routers/switches, whether or not the 515's are being used for NAT/ACL as
well as VPN, and some other details that would be necessary to weigh out all
the options. If it were mine to do, though, I would back up and look at
whether or not the 515's were worth keeping around. Honestly, if those
tunnels are important enough that there's a failover pair there, it might be
worth replacing them with concentrators that have better redundancy,
performance, and scalability. I'd also reconsider splitting the failover
pair if it can be avoided.
PaulM
<<
Yes, good luck is indeed graceful. As far as Vegas goes, the only thing I
ever did worthwhile there was to say "I do" while in a helicopter banking
over Circus Circus.
So, you're right, we need to be prepared for the worst. My backup plan for
the remote PIXie upgrades is to have a couple spares I can slap a config on
and FedEx out as needed. Asking the remote sites to figure out how to plug
in a modem, etc., is asking too much in this case.
As far as the 515's go, yeah, they're doing double duty [firewall and VPN
terminus], and I'd dearly love to put a VPN concentrator in place; but the
client has thus far been resistant to this line of thinking.
Thanks for the input, and the link to the IKE proposal table.
Regards,
Bob
_______________________________________________
firewall-wizards mailing list
firewall-wizards@honor.icsalabs.com
http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
- Next in thread: Robert L. Wanamaker: "RE: [fw-wiz] IP migration on "hub" VPN terminus [long]"
- Maybe reply: Robert L. Wanamaker: "RE: [fw-wiz] IP migration on "hub" VPN terminus [long]"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
