mforrence - I agree totally. I was looking for second opinions because that was the logic I was using as well, yet the vendor recommended against.
Thanks!
Thanks, I agree that terminating again would be probably best but the adapter isn't much more than a patch cable too.
My situation is that I can't just reterm and have it work with the old equipment. I don't want to put all the new equipment in and discover a problem requiring me to go back...
I'm not a fiber expert, most of my stuff is nice multimode. At a location we acquired, the previous business owners got single mode fiber installed for a "between two buildings" run (maybe 300 feet?).
Now we're getting to the point where we want to upgrade networking equipment, and everything...
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.
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...
definitely will need to add the statement 'crypto map corpvn interface DMZ'. I defined two crypto policies so I can tweak the settings on my second VPN link, and I use different vpngroups to do split tunneling on one but not the other. In my example, I have an interface "outside"...
It appears you have an issue in how your clients resolve DNS. Do they point at a DNS server inside or outside of your network? I assume an "nslookup [some dmz server]" doesn't work, but all other internet sites do?
Following up to what haknwak said, is your environment Microsoft...
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...
I'm running xauth for radius, using Cisco's sample documentation at http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a00800b6099.shtml
I'm using multiple vpngroups as well. Each one has its own key (no PKI...yet) and have different security definitions...
I'd be curious to hear anyones input on moving from 6.1(x) to 6.2(x) IF they are using multiple interfaces, site-to-site and client VPN, and failover. The failover stuff changes dramatically in 6.2 (no more serial cable, etc), and I'm not ready to leap like that in my environment!
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.
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...
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...
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!
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.