Setting up Cisco VPN behind DIR-655

T

tarzanbigcity

n00b
Joined
Dec 14, 2005
Messages
10
I was wondering if it was possible to add cisco vpn functionality by placing it behind my D-Link DIR-655 router. I am guessing i would need to forward all vpn ports. The DIR-655 doesn't have vpn functionality natively, so I figured this would be the best way to add such. I was thinking of going with a cisco pix 501 unit. Have you guys had any success in setting this up, and do you see any pitfalls to setting it up this way. Alternative suggestions are welcome also.

Thanks!
 
How about Hamachi VPN? Not as "Cool I use Cisco for my VPN"...but it's free, and doesn't care about firewalls. Or do you need access to the entire inside of your LAN?

Another free solution..SSL Explorer, open sourced....sourceforge.net
 
Unless the PIX is cheap/free, do yourself a favor and go for an ASA 5505. Second, unless you have a specific reason to run two firewalls, don't complicate things and just run one firewall. The ASA being the better option over the D-Link. Most cheapo router/firewalls don't support the proper forwarding for things like GRE and IPSEC in order to make what you have suggested work.

SSL Explorer is really nice for a free product. The free version doesn't support network extension though. You have to pay for that. The Cisco ASA firewall support SSL VPN with network extension, but you only get 2 free connections out of the box and have to license the feature above that.

Most of the businesses I support have purchased an ASA 5505. It has become the standard firewall I use.
 
Don't know if it's suitable for what you want, but i've got an IPCop box set up with the OpenVPN add on. Works flawlessly for my personal use and you've got the easy to use OpenVPN client for windows as well.
 
Ok, first off, the packets that are sent out through the vpn tunnel are not TCP, they're ESP. So they have no port, so they can't be NAT'd. Cisco has a way to beat that, by slapping a UDP header around it and making it port 4500, I doubt the D-Link does that. If you need help setting up a tunnel between Cisco devices, just pm me and I'll help you set it up.

Oh and VPN is not Cisco VPN, there is a client to site Cisco VPN client, and your SSL "VPN" can be broken by a twelve year old. Cisco VPN uses IKE to get a key and then DES/3DES/AES to encrypt it, I prefer AES 256, it's a CBC cipher and is the hardest to be broken, only large govt's can.

Or, google Openswan and try that on a linux box as your firewall.
 
Rabidfox said:
Oh and VPN is not Cisco VPN, there is a client to site Cisco VPN client, and your SSL "VPN" can be broken by a twelve year old.
Click to expand...

Even though I also prefer a traditional VPN (Agreed on the AES 256 part), I disagree with your statement. If an SSL VPN could be broken by a twelve year old, all of e-commerce would crumble as well. A properly set up SSL VPN can be as secure as a traditional client mode tunnel.
 
Rabidfox said:
Ok, first off, the packets that are sent out through the vpn tunnel are not TCP, they're ESP. So they have no port, so they can't be NAT'd. Cisco has a way to beat that, by slapping a UDP header around it and making it port 4500, I doubt the D-Link does that. If you need help setting up a tunnel between Cisco devices, just pm me and I'll help you set it up.

Oh and VPN is not Cisco VPN, there is a client to site Cisco VPN client, and your SSL "VPN" can be broken by a twelve year old. Cisco VPN uses IKE to get a key and then DES/3DES/AES to encrypt it, I prefer AES 256, it's a CBC cipher and is the hardest to be broken, only large govt's can.

Or, google Openswan and try that on a linux box as your firewall.
Click to expand...

Can you expand on why you feel SSL VPN's are not secure?
 
SSL can be broken by a bluecoat box in real time, 128 bit + piss algorithm.
 
Rabidfox said:
SSL can be broken by a bluecoat box in real time, 128 bit + piss algorithm.
Click to expand...

If you take the time to actually look at the cert BlueCoat hands you, you wouldn't trust it for private information:
http://thurston.halfcat.org/blog/2006/03/22/stuck-in-the-middle/

BlueCoat isn't breaking anything. It is handing you your its own public key, decrypting using its own private key, then re-encrypting using the public key of the site you are connecting to. If you configure your SSL VPN not to hand out your public key, then this is not possible. This is also called SSL bridging.

Something like this shows the importance of a trusted certificate chain. Just because it's "SSL Encrypted" doesn't mean you should trust the certificate or the person who issued it.

What it all comes down to is that this type of device will only work on a enterprise network where the admins are trying to control traffic of their users.This isn't really a threat out on the internet.
 
so, how do you not hand out your public key when authing with SSL? I sorta thought that was the point of public/private key authentication.
 
Rabidfox said:
so, how do you not hand out your public key when authing with SSL? I sorta thought that was the point of public/private key authentication.
Click to expand...

You can configure a web server to not hand out its public key. The user then must already have it. In an enterprise situation you have other means to distribute the key. Public/private key authentication still occurs, you are just limiting who has the public key. You can also configure client certificates to uniquely identify the user who is connecting.
 
yeah, AES256 rocks, oh you cracked my key? cool, have fun reading the first 256 bits of my data, now go crack another one, ad nauseum. That's my first choice, all the time, second is 3DES, if not that, I ask if I should be sending this data at all.
 
You must log in or register to reply here.
Back
Top