Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Need Multiple Interface IPSEC Example 1

Status
Not open for further replies.

sfrank8734

IS-IT--Management
Jan 10, 2003
27
US
Hello, I'm working on establishing another interface with IPSEC. I already have it running on one interface, and my 515E has available interfaces so we're experimenting with wireless access and using it as a vpn termination point. However, with the ipsec policy settings, I'm getting confused as to how to set up an additional one on the second interface. I am getting no response from the isakmp port (500) when initiating a session, and if I have an example I will bet I can figure my way through it.

The config is immense, we do a lot with our pix.

I have added the isakmp enable [interfacename], and I assumed that would bring up the isakmp port on the interface, but to no avail...

TIA!
 
HI.

What is the pix OS version? PDM?
The pix can use only a single default gateway.
Is the wireless access coming from the Internet, or from a specific IP subnet?
Is the wireless access going to be from notebook or handheld PC?

Try the following links:

Bye
Yizhar Hurwitz
 
OS is 6.1(4), not using PDM. Just a single subnet for the wireless network, I have static routes already defined and access in via ACLs to SSL-protected websites. Devices are handhelds and notebooks. I already have them coming in via the internet via VPN.

Thanks!

 
HI.

> Devices are handhelds and notebooks
As a side note, some handheld devices might benefit if you use a Cisco 3xxx VPN concentrator instead of the pix to terminate the VPN, because it supports DH group 7 which is special for such devices.
This can also simplify your tasks, but in a costly manner.

About the problems you have, try to post your configuration and some debug outputs from both clients and pix.
What is the purpose of the VPN - is it to provide encryption only? If so, you might consider using IPSec "transport" mode instead of "tunnel".
I don't have experience with wireless, but I think that there is a newer version of the protocol that has encryption at layer 2. Is this correct?

What is the VPN client in use? On what client OS?

Bye
Yizhar Hurwitz
 
The configuration is a monster, I have a site-to-site vpn tunnel set up with IPSEC, group 20, etc, and client vpn running from the internet. Debug crypto isakmp on the pix outputs produce nothing, I'm sniffing between my wireless network access point and the PIX and getting ICMP Port unreachables, so I don't have something right. The client tries 3 times, logs the attemtps, and says the peer didn't respond (this is a laptop, cisco aironet 350 card, etc).

I'm doing encryption and authentication, in fact with RADIUS on the wireless devices. WEP isn't secure enough, and we are in a busy office area where people like to snoop around. I also have a linux device in the middle (a router, iptables, etc.) that only allows trusted MAC addresses, and does some tricks with DHCP and DNS, and allows me to sniff the traffic on wires. That way if someone associates, just to peek, I will know it in seconds. Heh heh. It's all a pilot project, anyway.


There are lots of philosophical approaches to wireless, so there's lots to discuss. I'd like to keep the config the same so my roaming employees with laptops can use the Cisco client to connect from home the same way in the office (same methodology). Many are already using wireless devices on their home net, passing through an AP/Router with NAT, and doing IPsec into our network. (many = a dozen).

I'm curious about doing transport mode on an interface while maintaining the non-transport mode on the other interfaces. Possible? Then Microsoft VPN clients might work, but I unfortunately don't have a good test bed. That's right folks, we're playing on the production boxes, so I'm treading lightly.

The wireless devices are PocketPC 2002 devices, with 802.11b and ethernet (yes, wired) interfaces (CF cards we pop in and out, depending on where they are at--ethernet means inside the network, wireless means AP outside the firewall on it's own inteface and someday VPN back in). I'm using MovianVPN and it works like a charm--just like the Cisco VPN client on Windows in fact. Cost is a little heavy ($50 USD), but I'm inside the network pulling up intranet applications, etc just like I'm hard wired in. Yes, it handles the RADIUS request and prompts username and password as well. I'm quite impressed with it. My understanding is MovianVPN is available for Palm devices as well, but we've been slowly moving away from Palms because the raw functionality of PocketPCs is so great.

In the not-too-distant future, we'll be doing PDA with bluetooth to bluetooth data cellular phones (like a t-mobile or AT&T SonyEricsson T68i)--hopefully our US carriers will catch up with performance. I might be experimenting with wired phones (adapter cable to SprintPCS phone), but 16kbps throughput is pretty painful. Right now I'm using public access points (the local coffee shop) to VPN in.

I'll see what I can job out of the config and post it on Monday. I'm definitely curious what I'm missing.
 
HI.

> I'm sniffing between my wireless network access point and the PIX and getting ICMP Port unreachables
Right - I suggest that you open up ICMP on the linux box and try to ping from wireless to pix and vice versa.
Try also to temporarly allow telnet or virtual telnet from the wireless ip just to check if you can telnet to the pix (easier to check then IPSec troubleshooting).
Can the linux box ping the pix and vice versa?

ICMP port unreachable messages might be related to proxy arp problems, phisical network topology, ip addressing.
I would focus on the linux configuration.

After reading your last post, I think that an organization like you should consider dedicated VPN server, at least for the remote access VPN, for the following benefits:
* Support more VPN protocols (for example DH 7).
* Easier management and troubleshooting of VPN.
* Easier monitoring of VPN traffic.
* Offloading the pix (performance and complexity).
* Better control using access-list per user/group, and by filterring the clear text traffic at the pix.

However if you're going to purchase such device, you should check it capabilities for newer protocols like AES.

Bye
Yizhar Hurwitz
 
The linux box can reach the Pix without problems. I have a couple of services inside the network that are secured with SSL, so I've done some NAT and ACLs to allow access into those particular servers (two intranet servers, port 443), and these are easily accessible from the clients. So, overall connectivity is not a problem at all, that works splendidly.

A dedicated VPN device is under consideration--since this is a proof of concept project, I have to use what I have in front of me. Once I get people dependent on the functionality, I think it will be far easier to get funding for more devices. *smile*

I'll post relevant config a little later today. I'm still curious in solving the initial problem, regardless of what would be the best final solution--I need to have VPN clients come in on two different interfaces.

Thanks!

Steve
 
I'm getting it to work now, I hadn't properly applied my second crypto map. I can authenticate now, but now I have routing issues. I'll report back with updates later.







 
Can you tell me how you got your wireless to use VPN?
I just posted a question asking the same.

We successfully have IPsec VPn working for remote users.
Now I want to setup the wireless access point in a DMZ to also use ipSec VPN to gain access through the PIX to the company LAN. And still use VPN from home on the same laptops.


-steve
 
I'm using my AP on a separate interface on my PIX, but I just defined a second crypto policy and ACLs to let it through. It wouldn't be much different in your situation- define a crypto policy and apply it to your DMZ Interface, and add additional ACLs to allow the traffic. I personally would keep this separate, because your wireless traffic would be right next to your DMZ devices, which most likely wouldn't be self-firewalling from somebody who wardrives by and scans your network.

dmz interface ----------------dmz segment (mail/web)
|
|
|
wireless ap

Curious how you would be doing IP addresses--static assigned by the users, or would you be running a DHCP server in your DMZ, dishing out addresses within your DMZ segment?

By using a separate interface, I just use an RF1918 class C set, and I have a device doing DHCP on the wireless network (and a lot of other things).

I'm not sure if I'm answering your question:

My clients come in, plug in the wireless card. An IP address is given to them by my DHCP server sitting on the same segment as the access point (you could skip this part if you want to be a little more secure). The client has the unified client software with a separate IP address and vpngroup they use to connect to the interface on the pix, and they are in just like when they telecommute. My vpngroup is different because I don't do split tunneling for the wireless users--they must come into my network to see anything outside like the internet.

I probably muddled that up-give me more detail where you would like me to start.

 
You have certainly given me alot of new info that I will need. And I appreciate it!

Our setup is simple.

ISP
|
router
|
Outside Switch Vlan'd. (second vlan is the dmz below)
|
Pix -->dmz
|
Inside Switch
***************************

We don't have anything currently in our dmz.
I hope to have the wireless AP on the DMZ as per my questions.

Now more fun... Yes I want the Wireless AP to dole out DHCP addresses and then allow the VPN'd user to use that IP thru the firewall. In otherwords, the HDCP addresses would be the same subnet as the inside lan. The only difference for the wireless user would be the added path of going thru the VPN/firewall for security.

How would I change my config to support that? (see other post for config).

-steve

 
I'm not sure how to pull off what you are asking--the routing gets confusing, in terms of doing DHCP addresses externally that belong to your internal lan. I'd recommend a different segment, then you can add the routes to the PIX to find the second segment (so, say your ap is dishing out 192.168.1.20-40, you add a route dmz 192.168.1.0 255.255.255.0 statement to your config for the class C net). The real problem is that you cannot give a pix interface more than one IP address (or so I've been advised by my local Cisco reseller engeineers), which means you would have to dish out IP addresses from your DMZ subnet to really make this work. I think you might be stuck. Sorry!
 
That's was I was afraid of. What would you recommend as the best was to try to accomplish Wireless through the vpn? DMZ or otherwise? Maybe something in the line of having the vpn dish out the dhcp addresses?
 
Do you have another interface? That would be my suggestion. Then you can have your AP doing DHCP serving if you want on that other interface. See my config snippets in your other post.

The Pix itself cannot be a DHCP server. You'll have to put something on the segment to be a DHCP server.
 
Yes I do have three more unused interfaces; One nic for Ethernet0 another for Ethernet1 and a four port interface.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top