Hello All,
I'm having problems here is what I need:
I have someone at "XO comm" that runs a program that needs to access my 172.16.9.0/24 network, they do not need access to my 192.168.1.0/24 network. However I created an IPsec vpn for that, and it doesn't allow me to talk to the 172 network?? Any ideas? Sorry for my bad art, thought the diagram would explain it better!
THANK YOU!
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
Still no luck.. Could it have to do with the no forward?
interface Vlan1
nameif inside
security-level 100
ip address 192.168.1.1 255.255.255.0
!
interface Vlan2
nameif outside
security-level 0
ip address 7.1.4.6 255.255.255.248
!
interface Vlan3
description Connects to the Shell Robot PLC
<b>no forward interface Vlan1</b>
nameif dmz
security-level 50
ip address 172.16.9.1 255.255.255.0
I have some trouble understanding what is going on, since you have several tunnels configured.
I see in your diagram that "XO comm" is connecting from the outside.
Which tunnel-group do they use to connect? And which username?
Can you get a tunnel up and no traffic is passing? Or don't you get any connection at all?
Also, do your other tunnels work as expected?
Please let me know so I can help you further.
JG.
I've been going over your config. It's a bit confusing still, as you seem to have VPN enabled on every interface.
There are also a lot of options enabled on the group-policies.
I would personally remove:
crypto isakmp enable inside
crypto isakmp enable dmz
Unless you actually have users on the inside or dmz of your network connecting through VPN to your ASA to get somewhere.
Also this route:
route dmz 172.16.9.0 255.255.255.0 172.16.9.1 1
is a bit redundant, as that network is already configured on that interface to begin with.
However, I don't think these things should interfere with your VPN.
I assume that your regualer VPN users are actually able to connect. So what I want to do is remove the extensive group policy and recreate it with minimal requirements. To keep things clear.
In general you just want the vendor to connect the same way as your regular users, but just don't allow them to go into the LAN, but into the DMZ.
To make sure the vendor only get's to the DMZ I want to try using split tunneling. There are other ways, but I think this is the most straight forward at this point. If you don't agree with split tunnel I would suggest we first try to get the tunnel going and then look for another solution.
First take out the old policY:
no group-policy VendorGrpPolicy attributes
should take care of things, but make sure it is really gone.
First we need the split tunnel acl:
access-list SplitTunnelVendor standard permit 172.16.9.0 255.255.255.0
Now create a new policy:
group-policy VendorGrpPolicy attributes
vpn-tunnel-protocol IPSec l2tp-ipsec
split-tunnel-policy tunnelspecified
split-tunnel-network-list value SplitTunnelVendor
address-pools value VPNPool
We also need to exempt from NAT. We can use the same access-list that you already have:
nat (dmz) 0 access-list inside_nat0_outbound
Finally, I think you know this, but I wanted to make sure:
You have to create a seperate VPN profile to send to your vendor. I've created a screenshot of setting this up and attached it here.
Let me know how things turn out.
If you still can't connect, please post your revised config.
Good luck!
JG
VPN Profile example
Yes, I had the inside int enabled so I could test it from the inside network. I was able to get the VPN working on my own, however, I still cannot access the 172.16.9.x network..
I connect to the VPN, attempt to ping 172.16.9.50 and I get 100% packet loss, and on the firewall logs I see:
"No translation group found for icmp src inside:10.254.254.1 dst robotplc:172.16.9.50 (type 8, code 0)"
Does this have to do with the "no foward int vlan1" on the vlan 3 int?
Thank you!
Added that and still no go.. I'm really thinking its the no forward thats stopping it..? We have the base license, and from what I've read it sounds like you need the Security plus license to be able to do this...
Here's the code now >>
VPN is working..
Still no responses from ping 172.16.9.x network..
Here's a screenshot..
Attempt to ping from VPN address to the VLAN 3 subnet..
According to Cisco documentation this RPF is a mechanism in use to prevent spoofing attacks by checking the source of the ip address to the interface and checking if it should be coming from that interface, according to routing information:
This counter is incremented when ip verify reverse-path is configured on an interface and the security appliance receives a packet for which the route lookup of the source IP did not yield the same interface as the one on which the packet was received.
As you are in this case sure there is no spoofing attack going on, you might consider removing the "ip verify reverse-path" from the inside interface:
no ip verify reverse-path interface inside
See if that solves it.
I removed RPF from the inside interface, and I still can't access that vlan. Except now it's being stopped by an access list..
Packet Tracer result..
I'm still thinking this might be a licensing issue? With the no forward interface command stopping the pings/traffic.. ?
http://www.cisco.com/en/US
Can anyone confirm or denounce this?
Business Accounts
Answer for Membership
by: bmeyer1908Posted on 2009-08-05 at 13:13:43ID: 25027613
Try a static translation for the DMZ to the inside to the same IP addresses you have on nthe DMZ.
example: static (inside,DMZ) 167.141.67.0 167.141.67.0 netmask 255.255.255.0 0 0