|
|
 FAQ
 Search
 Memberlist
 Usergroups
 Register
 Profile
 Private messages
 Log in
|
|
| Author |
Message |
AJ
Guest
|
 Posted: Tue Apr 18, 2006 10:10 pm Post subject: Cisco VPN Client config on 515 |
 |
|
I am trying to get clients runnign Cisco VPN software to connect to my
internal network. currently the clients can connect and authenticate ok
but can't see anything on the inside network. I can not ping the client
from the 515. Here are the relevent config bits. I can not enable
"sysopt connection ipsec-enable" because of other VPN connections I
need to control traffic on. Any ideas?
Thanks,
--AJ
PIX Version 6.3(4)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
access-list acl_out_test permit icmp any any echo-reply
access-list acl_out_test permit icmp any any time-exceeded
access-list acl_out_test permit icmp any any unreachable
access-list acl_out_test permit icmp any any
access-list acl_out_test permit ip 10.0.18.0 255.255.255.0 host
10.0.0.212
access-list acl_out_test permit ip host 10.0.0.212 10.0.18.0
255.255.255.0
access-list VPNs permit ip 10.18.0.0 255.255.255.0 10.0.0.0 255.255.0.0
access-list VPNs permit ip 10.0.0.0 255.255.0.0 10.18.0.0 255.255.255.0
access-list VPNs permit ip 10.0.101.0 255.255.255.240 host 10.200.2.91
access-list VPNs permit ip 10.0.98.0 255.255.255.240 host 10.200.2.91
ip address outside xx.xx.xx.253 255.255.255.224
ip address inside 10.0.255.240 255.255.0.0
ip local pool VPNPOOL 10.18.0.1-10.18.0.20 mask 255.255.255.0
global (outside) 1 xx.xx.xx.227
nat (inside) 0 access-list VPNs
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
static (inside,outside) xx.xx.xx.225 10.0.0.208 netmask 255.255.255.255
0 0
static (inside,outside) xx.xx.xx.226 10.0.0.210 netmask 255.255.255.255
0 0
access-group acl_out_test in interface outside
route outside 0.0.0.0 0.0.0.0 xx.xx.xx.254 1
route inside 10.1.1.0 255.255.255.0 10.0.255.240 1
route inside 10.32.1.0 255.255.255.0 10.0.255.240 1
crypto ipsec transform-set VPNset esp-3des esp-md5-hmac
crypto dynamic-map cVPNdymap 10 set transform-set VPNset
crypto map VPNcrypto 10 ipsec-isakmp
crypto map VPNcrypto 10 match address VPNs
crypto map VPNcrypto 10 set peer xxx.xxx.xxx.251
crypto map VPNcrypto 10 set transform-set VPNset
crypto map VPNcrypto 65530 ipsec-isakmp dynamic cVPNdymap
crypto map VPNcrypto client authentication partnerauth
crypto map VPNcrypto interface outside
isakmp enable outside
isakmp key **************** address xxx.xxx.xxx.251 netmask
255.255.255.255
isakmp identity address
isakmp nat-traversal 20
isakmp policy 600 authentication pre-share
isakmp policy 600 encryption 3des
isakmp policy 600 hash md5
isakmp policy 600 group 2
isakmp policy 600 lifetime 86400
vpngroup TESTVPN address-pool VPNPOOL
vpngroup TESTVPN dns-server 10.0.0.202 10.0.0.212
vpngroup TESTVPN wins-server 10.0.0.202 10.0.0.212
vpngroup TESTVPN default-domain testdom.com
vpngroup TESTVPN idle-time 1800
vpngroup TESTVPN password ********************* |
|
| Back to top |
|
 |
|
|
Walter Roberson
Guest
|
| Posted: Tue Apr 18, 2006 11:57 pm Post subject: Re: Cisco VPN Client config on 515 |
|
|
In article <1145383803.848130.137150@t31g2000cwb.googlegroups.com>,
AJ <aragorn.m@gmail.com> wrote:
| Quote: | I am trying to get clients runnign Cisco VPN software to connect to my
internal network. currently the clients can connect and authenticate ok
but can't see anything on the inside network.
PIX Version 6.3(4)
access-list VPNs permit ip 10.18.0.0 255.255.255.0 10.0.0.0 255.255.0.0
access-list acl_out_test permit ip 10.0.18.0 255.255.255.0 host 10.0.0.212
ip local pool VPNPOOL 10.18.0.1-10.18.0.20 mask 255.255.255.0
nat (inside) 0 access-list VPNs
access-group acl_out_test in interface outside
crypto dynamic-map cVPNdymap 10 set transform-set VPNset
crypto map VPNcrypto 10 match address VPNs
|
That's the same access-list as you are using for your nat 0 access-list .
Don't try to reuse access-lists that way: there are some cases
where it is certain not to work properly, and there are other places
where there are bugs that cause it to work incorrectly. Safest is to
only any one ACL in one context.
| Quote: | crypto map VPNcrypto 65530 ipsec-isakmp dynamic cVPNdymap
vpngroup TESTVPN address-pool VPNPOOL
|
Your VPN clients are going to be allocated an IP from VPNPOOL,
which is part of 10.18.0/24 . These IPs will be "outside" as far as
the PIX is concerned. Traffic from inside towards those IPs will therefore
have a *destination* IP in 10.18.0/24 . That destination does not
match your nat 0 access-list, so the traffic will be NAT'd as it goes
outwards. If we hypothesize that the return traffic will use the allocated
private IP as its source, then that private IP is not going to match
the traffic expected by the Adaptive Security Algorithm (which would
be expecting the NAT'd IP) and so the traffic would be dropped. If
we hypothesize that the return traffic will have the NAT'd IP as its
source, then that NAT'd IP will not match the acl_out_test access-list
so the traffic would be denied.
If you try to fix the nat 0 access-list by just reversing the source
and destination fields, such as
access-list VPNs permit ip 10.0.0.0 255.255.0.0 10.18.0.0 255.255.255.0
then the outbound traffic would not be NAT'd. However, the non-NAT'd
outbound traffic would then match the occurance of the same line in
"crypto map VPNcrypto 10 match address VPNs" and so the outbound traffic
would be grabbed by your regular VPN tunnel [which has a higher priority
because it has a lower policy number] and sent there instead of
proceeding to the VPN client dynamic-map policy entry that would allow
the traffic to get back to the VPN client.
Probably what you want to do is eliminate the above line from the
access-list you match against in your crypto policy, but still include
it in the access-list you match against for nat 0 access-list . Which
is another good reason for not attempting to re-use ACLs in different
contexts -- you get unintended consequences.
| Quote: | crypto map VPNcrypto client authentication partnerauth
isakmp key **************** address xxx.xxx.xxx.251 netmask 255.255.255.255
|
The first of those two indicates that the crypto client is to be
authenticated against the service you named "partnerauth"; this
enables the Xauth mechanism. The isakmp key statement does NOT have
no-xauth, so xauth will apply to the remote host xxx.xxx.xxx.251
that is using your VPNcrypto 10 policy entry. Was that your intention,
or did you mean the "partnerauth" authentication to apply only to
the dynamic clients ? |
|
| Back to top |
|
|
AJ
Guest
|
| Posted: Wed Apr 19, 2006 1:40 am Post subject: Re: Cisco VPN Client config on 515 |
|
|
OK so separating the ACLs from the NAT and the Crypto commands seams to
have done the trick. Thanks for all the help!
So it works but I am wondering just how secure it is...
Essentially I will end up with an ACL on my outside interface allowing
10.18.0.0/24 into my internal network (I know I can control ports and
destination IPs etc) but this is my protected network. Is this a good
idea? Granted the IP on my outside interface has a public IP but isn't
it possible to get packets to arrive at the outside interface which
appear to originate from 10.18.0.0/24 without that traffic going over
my VPN tunnel?
Is there better way?
--AJ |
|
| Back to top |
|
|
Walter Roberson
Guest
|
| Posted: Wed Apr 19, 2006 5:23 am Post subject: Re: Cisco VPN Client config on 515 |
|
|
In article <1145396405.016488.231300@g10g2000cwb.googlegroups.com>,
AJ <aragorn.m@gmail.com> wrote:
| Quote: | So it works but I am wondering just how secure it is...
Essentially I will end up with an ACL on my outside interface allowing
10.18.0.0/24 into my internal network (I know I can control ports and
destination IPs etc) but this is my protected network. Is this a good
idea? Granted the IP on my outside interface has a public IP but isn't
it possible to get packets to arrive at the outside interface which
appear to originate from 10.18.0.0/24 without that traffic going over
my VPN tunnel?
|
Yes, if the sending network does not follow RFC1918 rules and permits
10.18.0/24 to be pass out of their network, then it is possible that
nothing inbetween will filter the packets, and that they would arrive
at your PIX interface if they are addressed to any of your public IPs.
If you are using private IPs internally, part of the solution to that is to
permit the private IPs of the VPN to go only to the private IPs of the
LAN: then the packets would not be able to get to your PIX unless
the next-hop for some reason routes that IP range to your PIX.
Even if you do not do that, the PIX should notice that the source IP
was not received over the VPN as expected and should drop the packet.
The message is roughly "Received packet is not an IPSec packet".
The PIX actively checks for IPs that should be tunneled but which are
arriving directly. |
|
| Back to top |
|
|
|
|
