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!

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

PIX501 - Client VPN routing issue

Status
Not open for further replies.
Myster

Myster

IS-IT--Management
Feb 16, 2005
18
DE
Hi everybody !

I've browsed the forum a lot without finding anyone having the same issue as i do... so here is my post :)...

The configuration is as follow:
- 2 sites connected by VPN (working correctly)
- on each site, PIX-501 - v6.3(3)

I'm trying, beside the site-to-site VPN, to setup remote access with Cisco VPN Client 4.6.
I configured one of the PIX with vpngroup to make my tests, I will later change the auth method to something else (either local or radius).

Here is the point :
At home, with my laptop, I "dial" the VPN connection through Cisco VPN Client. Everything wents OK, and the VPN seems to be established. The laptop is wired on local LAN and goes through an IPTABLES firewall. It uses UDP and UDP-500 port is
forwared correctly to my laptop.

Once the VPN is established, I try to ping a Linux box which is connected on the DMZ, so directly after the PIX, without success.

The network debug I made gave :
- the ICMP requests reach the Linux box and it answers to them (used tcpdump and saw incoming and outgoing packets)
- the laptop never gets the replies.
- watching the logs on my Iptables, I see nothing dropped
- I've tested other kind of access (POP, SMTP, HTTP,...) and had each time the same symptoms.

My first idea is that there's a routing or ACL issue on my PIX that blocks the returning packets.

Network "diagram" :


Remote Office with 10.3.3.0/24 & 192.168.2.0/24
PIX-501
/
/
/
/
-----------
| Internet |------------ Home IpTables FW ------ Laptop
-----------
\
\
PIX-501
|
|
10.12.1.0/24 DMZ
|
|
Internal IPTABLES FW
|
|
192.168.70.0/24 Internal LAN



Here my PIX configuration :

PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 100full
nameif ethernet0 outside security0
nameif ethernet1 inside security100
[...]
names
name 195.XXX.XXX.11 ldeml01-I
name 10.12.1.4 ldeml01-D
name 195.XXX.XXX.30 Kiwi-I
name 10.12.1.30 Kiwi-D
name 10.12.1.16 ST16-D
name 10.12.1.3 lddmz01-D
name 10.12.2.0 ld_ras_lan
name 82.XXX.XXX.225 else_home
name 82.XXX.XXX.176 somewhere_home
name 195.XXX.XXX.10 LDAPP01-I
access-list 101 permit ip 192.168.70.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list 101 permit ip 10.12.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list 101 permit ip 192.168.70.0 255.255.255.0 10.3.3.0 255.255.255.0
access-list 101 permit ip 10.12.1.0 255.255.255.0 10.3.3.0 255.255.255.0
access-list 101 permit ip ld_ras_lan 255.255.255.0 192.168.70.0 255.255.255.0
access-list 101 permit ip ld_ras_lan 255.255.255.0 10.12.1.0 255.255.255.0
access-list 101 permit ip 192.168.70.0 255.255.255.0 ld_ras_lan 255.255.255.0
access-list 101 permit ip 10.12.1.0 255.255.255.0 ld_ras_lan 255.255.255.0
access-list 200 permit tcp any host ldeml01-I eq https
access-list 200 permit tcp any host ldeml01-I eq imap4
access-list 200 permit tcp any host ldeml01-I eq smtp
access-list 200 permit tcp any host 195.XXX.XXX.1 eq domain
access-list 200 permit udp any host 195.XXX.XXX.1 eq domain
access-list 200 permit tcp any host 195.XXX.XXX.111 eq www
access-list 200 permit tcp any host 195.XXX.XXX.111 eq https
access-list 200 permit tcp any host 195.XXX.XXX.108 eq www
access-list 200 permit tcp any host Kiwi-I eq www
access-list 200 permit tcp any host Kiwi-I eq https
access-list 200 permit tcp any host 195.XXX.XXX.31 eq www
access-list 200 permit tcp any host 195.XXX.XXX.31 eq https
access-list 200 permit tcp host 62.XXX.XXX.29 host ldeml01-I eq ssh
access-list 200 permit tcp host 81.XXX.XXX.90 host ldeml01-I eq ssh
access-list 200 permit tcp any host 195.XXX.XXX.1 eq https
access-list 200 permit tcp any host 195.XXX.XXX.2 eq www
access-list 200 permit tcp any host ldeml01-I eq www
access-list 200 permit tcp any host 195.XXX.XXX.4 eq https
access-list 200 permit tcp host somewhere_home host ldeml01-I eq ssh
access-list 200 permit tcp host 82.XXX.XXX.114 host ldeml01-I eq ssh
access-list 200 permit tcp host else_home host ldeml01-I eq ssh
access-list 200 permit tcp any host 195.XXX.XXX.1 eq 2401
access-list 200 permit tcp any host 195.XXX.XXX.1 eq ssh
access-list 200 permit icmp any any echo-reply
access-list 200 permit tcp any host LDAPP01-I eq www
no pager
icmp permit 10.12.1.0 255.255.255.0 echo outside
mtu outside 1500
mtu inside 1500
ip address outside 195.XXX.XXX.1 255.255.255.128
ip address inside 10.12.1.1 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool ld_ras_pool 10.12.2.32-10.12.2.63
pdm history enable
arp timeout 14400
global (outside) 1 195.XXX.XXX.3 netmask 255.255.255.255
nat (inside) 0 access-list 101
nat (inside) 1 10.12.1.0 255.255.255.0 0 0
nat (inside) 1 192.168.70.0 255.255.255.0 0 0
static (inside,outside) tcp interface domain lddmz01-D domain netmask 255.255.255.255 0 0
static (inside,outside) udp interface domain lddmz01-D domain netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https lddmz01-D https netmask 255.255.255.255 0 0
static (inside,outside) tcp 195.XXX.XXX.1 2401 lddmz01-D 2401 netmask 255.255.255.255 0 0
static (inside,outside) ldeml01-I ldeml01-D netmask 255.255.255.255 0 0
static (inside,outside) 195.XXX.XXX.111 ST16-D netmask 255.255.255.255 0 0
static (inside,outside) 195.XXX.XXX.108 10.12.1.108 netmask 255.255.255.255 0 0
static (inside,outside) 195.XXX.XXX.31 10.12.1.31 netmask 255.255.255.255 0 0
static (inside,outside) Kiwi-I Kiwi-D netmask 255.255.255.255 0 0
static (inside,outside) 195.XXX.XXX.4 10.12.1.14 netmask 255.255.255.255 0 0
static (inside,outside) 195.XXX.XXX.2 10.12.1.6 netmask 255.255.255.255 0 0
static (inside,outside) LDAPP01-I 10.12.1.5 netmask 255.255.255.255 0 0
access-group 200 in interface outside
route outside 0.0.0.0 0.0.0.0 195.XXX.XXX.126 1
route inside 192.168.70.0 255.255.255.0 10.12.1.2 1
timeout xlate 1:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225 1:00:00
timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server LOCAL protocol local
ntp server 84.XXX.XXX.38 source outside
snmp-server host inside 192.XXX.XXX.18 poll
no snmp-server location
no snmp-server contact
snmp-server community XXXXXXXXX
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set toyota esp-des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set toyota
crypto map bmw 1 ipsec-isakmp
crypto map bmw 1 match address 101
crypto map bmw 1 set peer 66.XXX.XXX.4
crypto map bmw 1 set transform-set toyota
crypto map bmw 20 ipsec-isakmp dynamic dynmap
crypto map bmw interface outside
isakmp enable outside
isakmp key ******** address 66.XXX.XXX.4 netmask 255.255.255.255
isakmp identity address
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 lifetime 1000
vpngroup groupras address-pool ld_ras_pool
vpngroup groupras dns-server lddmz01-D
vpngroup groupras default-domain XXXXXXXXXXX.local
vpngroup groupras idle-time 1800
vpngroup groupras password ********
telnet timeout 5
ssh 66.XXX.XXX.10 255.255.255.255 outside
ssh else_home 255.255.255.255 outside
ssh 10.12.1.0 255.255.255.0 inside
ssh timeout 10
console timeout 10
terminal width 120

I hope I gave enough info to get some help :) !
 
Sort by date Sort by votes
Just a quick look, I didn't do a detailed anlaysis.

This is obviouly an access problem.

I would add your pool of addresses for the VPN Clients to the 101 access-list so they bypass NAT. You do this through the NAT (inside) 0 command. This may fix your issue.


It is what it is!!
__________________________________
A+, Net+, I-Net+, Certified Web Master, MCP, MCSA, MCSE, CCNA, CCDA, and few others (I got bored one day)
 
Upvote 0 Downvote
Hi,

Thanks for your answer but the VPN pool (named ld_ras_lan) is already included in the 101 access-list that by passes outgoing nat... :)

Any other idea(s) ? ;-)
 
Upvote 0 Downvote
Just a quick thought.
Whats the MTU size on your SoHo connection? Some aDSL providers don't like it when its at default settings (1500). This causes "un-neccessary" fragmentation, because the added crypto makes the packages exceede the 1500 packet size limit (MTU size).
You'll experience a successful VPN connection, but what's happening is that packages are being dropped.
Usually setting the MTU size to somewhere between 1300-1400 fixes the problem. This can be done using Cisco own "Set MTU" utility in the program menu.

Just my 2 cents :)
 
Upvote 0 Downvote
OK, thanks, I will try changing MTU.

Anyway, as explained in my first email,
i see incoming packets on the server i'm trying to ping, outgoing response packets on the same server (using tcpdump on the interface), but theses response packets do never reach the client (ethereal on the client).

So IMO its something more PIX related, don't you think ? :-(
 
Upvote 0 Downvote
I've tried changing MTU size (which was already set to 1300 so that *should* have worked already before), but i still don't have returning packets.

This is becoming quite urgent (as usual..) as our CEO will need RAS VPN access by the end of the week...

Please help ;-)
 
Upvote 0 Downvote
Here are some other infos :

Result of "debug isakmp" command obtained in 15-20 seconds :

crypto_isakmp_process_block:src:else_home, dest:195.XXX.XXX.1 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 36136 protocol 1
spi 0, message ID = 1452642716
ISAMKP (0): received DPD_R_U_THERE from peer else_home
ISAKMP (0): sending NOTIFY message 36137 protocol 1
return status is IKMP_NO_ERR_NO_TRANS
ISADB: reaper checking SA 0xac3f74, conn_id = 0
ISADB: reaper checking SA 0xab1f94, conn_id = 0
crypto_isakmp_process_block:src:else_home, dest:195.XXX.XXX.1 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 36136 protocol 1
spi 0, message ID = 901408428
ISAMKP (0): received DPD_R_U_THERE from peer else_home
ISAKMP (0): sending NOTIFY message 36137 protocol 1
return status is IKMP_NO_ERR_NO_TRANS
crypto_isakmp_process_block:src:else_home, dest:195.XXX.XXX.1 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 36136 protocol 1
spi 0, message ID = 406743411
ISAMKP (0): received DPD_R_U_THERE from peer else_home
ISAKMP (0): sending NOTIFY message 36137 protocol 1
return status is IKMP_NO_ERR_NO_TRANS
crypto_isakmp_process_block:src:else_home, dest:195.XXX.XXX.1 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 36136 protocol 1
spi 0, message ID = 4292750588
ISAMKP (0): received DPD_R_U_THERE from peer else_home
ISAKMP (0): sending NOTIFY message 36137 protocol 1
return status is IKMP_NO_ERR_NO_TRANS
crypto_isakmp_process_block:src:else_home, dest:195.XXX.XXX.1 spt:500 dpt:500
ISAKMP (0): processing NOTIFY payload 36136 protocol 1
spi 0, message ID = 976947345
ISAMKP (0): received DPD_R_U_THERE from peer else_home
ISAKMP (0): sending NOTIFY message 36137 protocol 1
return status is IKMP_NO_ERR_NO_TRANS

Does this help ?
 
Upvote 0 Downvote
here's my working IPSec Cisco Client 4.6 config.

access-list outside_cryptomap_dyn_30 permit ip any 193.100.3.0 255.255.255.128
ip local pool cssbh 193.100.3.30-193.100.3.75
nat (inside) 0 outside_cryptomap_dyn_30
sysopt connection permit-ipsec
crypto ipsec transform-set myset esp-des esp-md5-hmac
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map dynmap 10 set transform-set myset
crypto dynamic-map dynmap 30 match address outside_cryptomap_dyn_30
crypto dynamic-map dynmap 30 set transform-set ESP-3DES-MD5
crypto map mymap 10 ipsec-isakmp dynamic dynmap
crypto map mymap client configuration address initiate
crypto map mymap client configuration address respond
crypto map mymap interface outside
crypto map outside_map client authentication RADIUS
isakmp enable outside
isakmp identity address
isakmp client configuration address-pool local cssbh outside
isakmp nat-traversal 20
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 1
isakmp policy 10 lifetime 86400
isakmp policy 30 authentication pre-share
isakmp policy 30 encryption 3des
isakmp policy 30 hash md5
isakmp policy 30 group 2
isakmp policy 30 lifetime 86400
vpngroup cssbh address-pool cssbh3
vpngroup cssbh dns-server cssnt01 cssnt03
vpngroup cssbh wins-server cssnt01
vpngroup cssbh default-domain xxxx.org
vpngroup cssbh idle-time 600
vpngroup cssbh password ********

Computer/Network Technician
CCNA
 
Upvote 0 Downvote
Hello,

I tried adapting my conf according to the one you provided me, but it's not working... In fact, is event worse !

I don't understand your ACL. Is the 193.100.3.0/25 your VPN pool or is it your public IP plan .

When I added the statement :
"access-list 101 permit ip any 10.12.2.0 255.255.255.0"
i could no longer establish the VPN. I had to remove this ACL statement to be able again to establish it.

Could someone make an "in-depth" analysis of my config ?

I've collected info from several forums, google searches, Cisco web-site templates, etc... but, as I'm quite new with VPNs, even more on PIX, I cant't figure out what's missing or what's wrong...

Thanks !
 
Upvote 0 Downvote
Hello again, Myster.

Looks like you have yourself a little mystery on your hands here (sorry.. bad joke) :)
First of all, your ACL 101 is a general one and not connected to any specific "interface" as I can see. What you need to be looking at is your ACL 200. I think you're missing a statement saying something like this:
access-list 200 permit ip 10.12.2.32 255.255.255.224 10.12.1.0 255.255.255.0
This access-list allow all traffic from the VPN clients to your inside network.
You should also add mask 255.255.255.224 statement at the end of the ip local pool ld_ras_pool 10.12.2.32-10.12.2.63 (Unless you're happy with the 255.255.255.0 ofcourse. Mearly suggesting that you subnet your VPN pool).

Furthermore, have you concidered using named ACL's? It's by far more easier to relate to than numbers. It's been scientifically proven too:)
Having ACL's matching the names of your interfaces makes it a bit more intuitive to work with aswell:

Code: 
access-group outside in interface outside
access-group inside in interface inside
access-group dmz in interface DMZ

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
I just noticed that you're missing another statement in you ACL 200:
Code: 
access-list 200 permit udp any host [PIX outside IP address] eq isakmp
This line accepts UDP 500, which is your VPN tunell :)

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
Thanks for your answer,

First of all, to make things easier in a first time, I will change the VPN pool to a full C class range (10.12.2.0/24).
As you suggested it, I will also add in the ACL 200 the line about this pool, but something still seems strange to me :
- as the VPN tunnel can be established between the client and the PIX, and packets from client -> server behind PIX are passing correctly through the PIX, will the ACL statement concerning isakmp have sense ? (only returning packets do not reach the client).
- on the other hand, doesn't the statement "sysopt connection permit-ipsec" enable incoming encrypted communications ?

By the way, I made other investigations yesterday night, and enable "debug icmp trace" while doing pings from my client to the server, and I saw both echo and echo replies on the pix, but nothing got through the VPN...

The 101 ACL is used to define NAT 0, and will eventually be used in case of split-tunneling (which will certainly be my next issue :))

I'm sorry about using numbered ACL, but his is how I learned it 6 years ago and... ;-)

Conclusion : I will try everything you suggest and give you some feedback :)
 
Upvote 0 Downvote
You're right about the sysopt statement, Myster. By using the sysopt connection permit-ipsec command, the inbound ipsec traffic bypasses all access-lists and counduits. That last entry in the ACL 200 isn't needed at all. And since you can't block inbound traffic on the internal interface as you can with a cisco router, the traffic cannot be filtered at this point. To lock this traffic down, use ACLs without using the sysopt command.
I guess when I initially configured my PIX, this ACL statement got left in there, and I haven't changed it since :)
I'll look forward to your feedback on how things turned out. Good luck!

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
I'm sorry about using numbered ACL, but his is how I learned it 6 years ago and...
Click to expand...
No need to be sorry. If you're used to using numbered ACL, and it works for you, why change it. I was mearly making a suggestion :)

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
Well well well...

First of all, my VPN pool is now the 10.12.2.0/24 full range.
I've added the ACL statement as you told me to :
access-list 200 permit ip 10.12.2.0 255.255.255.0 10.12.1.0 255.255.255.0

But, after analysis of this statement, there are some things I do not found "logical" :
- the sysopt statement allows incoming ISAKMP traffic
- the 10.12.2.0 network is "encapsulated" in the VPN, so in ISAKMP.... then, in my mind, the VPN pool addresses never reach the "outside" interface of the PIX, but is routed by internal mechanisms. So if i follow this idea, adding this network in the 200 ACL is useless.

I know I'm always repeating the same thing, but, once again, the packets sent by the client are going correctly through the VPN, the PIX, reach the server, which responds, but the packets are not encapsultated back into the VPN, so they never arrive to the client.

So, my idea (but I may be wrong), is that the PIX needs to know that packets having 10.12.2.0/24 as destination must be encrypted and "routed" through the VPN... but I f**** don't no how to tell this to the PIX. I can imagine that it's something "implicit" done by a statement that doesn't explicitly "means" this process....

I've that strange feeling that I'm trying to catch my own tail :)
 
Upvote 0 Downvote
I see your point Myster.
first of all, to clear out any misunderstandings. By using the sysopt connection permit-ipsec, you're effectivly bypassing all you ACLs for everyone with a successful VPN connection. So you're right when saying you don't need that ACL 200 statement I provided for you. But leave it in. At some point you "might" concider tightening the security a bit ;)
Secondly, I want you to look at your NONAT statements. Are you NATing traffic to your 10.12.2.0 network? If you are, you should use an ACL that negates this:

Code: 
nat (inside) 0 access-list NoNat
access-list NoNat permit ip 10.12.1.0 255.255.255.0 10.12.2.0 255.255.255.0

Your ideas are good, but you don't have to tell the PIX all this for each connection. It will know this by checking the crypto statements. Once it recognizes inbound IPSEC, it will await an authorization. If it's successful, then the connection is allowed to go anywhere. And as the PIX is a stateful firewall, it will know where to send any return traffic. This is from a security point of view. Crypto packets won't bypass the NAT or GLOBAL statements. So these needs to be configured properly too.
I'm sure I'm not explaining all this properly, but I hope you get my point. By adding/modifying the above lines to your existing configuration, your VPN connections should be successful and allow you unlimited access.

Now this is on the PIX level. I noticed that you NAT even further here. Are these static or dynamic?
Eg.
192.168.70.1 NATed to -> 10.12.1.1

Because your VPN clients will only see 10.12.1.1, and not the real host (192.168.70.1).
What type of firewall do you have guarding your internal LAN?

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
Ok,

I see what you mean and I understand your explanations.

These are excerpts from the whole config, as stated at the beginning of my post :

Code: 
name 10.12.2.0 ld_ras_lan
[...]
ip local pool ld_ras_pool 10.12.2.1-10.12.2.254
[...]
access-list 101 permit ip 192.168.70.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list 101 permit ip 10.12.1.0 255.255.255.0 192.168.2.0 255.255.255.0
access-list 101 permit ip 192.168.70.0 255.255.255.0 10.3.3.0 255.255.255.0
access-list 101 permit ip 10.12.1.0 255.255.255.0 10.3.3.0 255.255.255.0
[b]access-list 101 permit ip ld_ras_lan 255.255.255.0 192.168.70.0 255.255.255.0
access-list 101 permit ip ld_ras_lan 255.255.255.0 10.12.1.0 255.255.255.0
access-list 101 permit ip 192.168.70.0 255.255.255.0 ld_ras_lan 255.255.255.0
access-list 101 permit ip 10.12.1.0 255.255.255.0 ld_ras_lan 255.255.255.0 [/b]
[...]
nat (inside) 0 access-list 101
nat (inside) 1 10.12.1.0 255.255.255.0 0 0
nat (inside) 1 192.168.70.0 255.255.255.0 0 0

So, as you can see, the VPN pool is included in the "no NAT" rule (ACL 101). This shoud avoid NAT when packets are concerning internal networks (10.12.1.0/24 and 192.168.70.0/24), the VPN pool (10.12.2.0/24) and the remote site addresses.

I don't see where static NAT is done for addresses 10.12.1.1 and 192.168.70.1 ???
Our internal FW, between DMZ and INT zone, is based on IPtables. But at this time, this has no impact on my issue, as I'm trying to reach a machine wich is in DMZ.

Here is a simplified diagram of the architecture :
Code: 
                    ------------------
VPN Client =========|Home iptables FW|=====> PIX 501 =====> Server on DMZ
10.12.2.1            -----------------                        10.12.1.4

Maybe should I try bypassing my home FW and plug my laptop directly on the Internet. My IPTables FW seems OK, as there's no event regarding the VPN connection in its logs. But we never know.

By the way, you are speaking about crypto statements.
Here is my current configuration :

Code: 
sysopt connection permit-ipsec
crypto ipsec transform-set toyota esp-des esp-md5-hmac 
crypto dynamic-map dynmap 10 set transform-set toyota
crypto map bmw 1 ipsec-isakmp
crypto map bmw 1 match address 101
crypto map bmw 1 set peer 66.XXX.XXX.4 (this is our remote office IP)
crypto map bmw 1 set transform-set toyota
crypto map bmw 20 ipsec-isakmp dynamic dynmap
crypto map bmw interface outside
isakmp enable outside
isakmp key ******** address 66.XXX.XXX.4 netmask 255.255.255.255 
isakmp identity address
isakmp client configuration address-pool local ld_ras_pool outside
isakmp policy 1 authentication pre-share
isakmp policy 1 encryption des
isakmp policy 1 hash md5
isakmp policy 1 group 2
isakmp policy 1 lifetime 1000
vpngroup groupras address-pool ld_ras_pool
vpngroup groupras dns-server lddmz01-D
vpngroup groupras default-domain company.local
vpngroup groupras idle-time 1800
vpngroup groupras password ********

Explanations :
- crypto map bmw is used to establish the site to site VPN with our remote office
- crypto map dynamic-map is used for VPN clients
- isakmp policy 1, is, in my understanding, used for the site to site VPN, but *maybe* also used by client conf (???).

Do you see something missing ? I've tried reproducing some kind of config LloydSev provided in this post, but doing so leaded to nor site to site neither client VPNs worked, so I had to roll-back very quickly :).

Thanks for all the time you spend helping me !

Myster
 
Upvote 0 Downvote
The reason for my question is this little overview you provided:
Network "diagram" :


Remote Office with 10.3.3.0/24 & 192.168.2.0/24
PIX-501
/
/
/
/
-----------
| Internet |------------ Home IpTables FW ------ Laptop
-----------
\
\
PIX-501
|
|
10.12.1.0/24 DMZ
|
|
Internal IPTABLES FW
|
|
192.168.70.0/24 Internal LAN
Click to expand...
From what I can see, you've placed your DMZ zone inbetween your internal LAN and your PIX. Is this correct?
I have to admit that it confused me a little, and I had to look up the 501 Product Overview on the Cisco pages. Seems I made a mistake of presuming you had 3 interfaces, when you only had "2". One is to connect to your xDSL/MoDem/router and the other(s) (the 4 port internal switch) is for internal usage. can you separate traffic on these 4 ports or are they regarded as "one common interface"?

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
The problem is.. you have one VPN configuration for your site to site and have not added another configuration for clients as well.

crypto dynamic_map is a generic crypto config line.

crypto map bmw is for the site to site
crypto map <whatever> would need to be created for the vpn clients.

also, you would need a new isakmp policy as well to cover the new vpn clients.

Computer/Network Technician
CCNA
 
Upvote 0 Downvote
Why would he need another policy? The one he's using now seems just fine. Unless he wants to use a different set of security rules for his VPN users, I see no need to have another one. Perhaps changing the encryption from DES to 3DES, but no major changes needs to be made.
Code: 
crypto map bmw interface outside
This line will prevent him from using any additional crypto maps, as the PIX can only use one crypto map per interface at any given time. I don't know if this has changed in 7.0(1), but as Myster is currently using 6.3(3) this can't be achieved.

Based on this I have to disagree with you LloydSev. Myster is in no need of additional crypto maps, or another policy rule.
What appears to be missing is a line similar to this:
Code: 
crypto map bmw client authentication [authentication-method]
I've probably missed that line somewhere, as he seems to connect just fine. But I'd like to get it confirmed that it exists. And also my original question about the network diagram please :)

A firm beleiver of "Keep it Simple" philosophy
Cheers
/T
 
Upvote 0 Downvote
Status
Not open for further replies.

Similar threads

intel233
  • Locked
  • Question
Cisco ASA - VPN Question
Replies
6
Views
554
intel233
intel233
ISDPCMAN
  • Locked
  • Question
RDP fails over VPN
Replies
1
Views
201
gkittelson
gkittelson
Shmid
  • Locked
  • Question
Restricting Sonicwall SSL-VPN users for WAN access
Replies
7
Views
686
Shmid
Shmid
WhosYourDiffie
  • Locked
  • Question
Cisco ASA 5506 VPN for Avaya Phones
Replies
0
Views
142
WhosYourDiffie
WhosYourDiffie
Tommy_T
  • Locked
  • Question
Sonic wall - Have an issue remotely connectioning VNC and SMB (and AFP) to one of the 2 ISP circuits
Replies
1
Views
497
nnaarrnn
nnaarrnn

Part and Inventory Search

Sponsor

Back
Top