Buy or Renew
Buy or Renew
Duo Security forums now LIVE! Get answers to all your Duo Security questions. Learn more
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
385
Views
5
Helpful
4
Replies

Can PIX be configured for VPN using IPSec and PPTP at the same time ?

li.simon
Level 1
Level 1

‎08-18-2003 02:57 PM - edited ‎02-21-2020 12:43 PM

Dear Sir,

We have 2 PIXen (PIX525 and PIX515). Both PIXen are configured for VPN Remote Access using PPTP and working good. Now we want to add Site-to-Site VPN using IPSec on both PIXen by following this doc link http://www.cisco.com/warp/public/110/38.html

I have experienced the following problem:

1. I need two "NAT (Inside) 0" statement for two different access-list #. One ACL# is for PPTP VPN and one ACL# is for IPSec VPN. But PIX only accepts one "NAT (Inside) 0" statement. The second "NAT (Inside) 0" statement will overwrite the first one. What Can I do?

Access-list 101 permit ip 192.168.100.0 255.255.255.0 192.168.101.0 255.255.255.0 (for PPTP VPN traffic)

access-list 102 permit ip 192.168.100.0 255.255.255.0 172.16.0.0 255.255.0.0 (for IPSec VPN traffic)

nat (inside) 0 access-list 101

nat (inside) 0 access-list 102

PIX can only accept one NAT(0) statement above.

2. If I combine both VPN traffic into one ACL# and use one "nat (inside) 0" statement, my PPTP VPN for remote access will not work because of "crypto map mapname 1 match address 101" statement in IPSec configuration.

Access-list 101 permit ip 192.168.100.0 255.255.255.0 192.168.101.0 255.255.255.0 (for PPTP VPN traffic)

access-list 101 permit ip 192.168.100.0 255.255.255.0 172.16.0.0 255.255.0.0 (for IPSec VPN traffic)

nat (inside) 0 access-list 101

crypto map mapname 1 match address 101

My PPTP VPN will not work with above "crypto map mapname 1 match address 101" statment. If "crypto map mapname 1 match address 101" statement is removed, then PPTP VPN will work fine.

Can someone help me to resolve above issue?

Thanks,

Simon

Labels:
0 Helpful
4 Replies 4

gfullage
Cisco Employee
Cisco Employee

‎08-18-2003 04:33 PM

Yes, you can do this, you need to create a couple of access-lists though.

First off, as you said, combine your two "nat 0" acl's into one ACL as follows:

access-list nonat permit ip 192.168.100.0 255.255.255.0 192.168.101.0 255.255.255.0

access-list nonat permit ip 192.168.100.0 255.255.255.0 172.16.0.0 255.255.0.0

nat (inside) 0 access-list nonat

Then have your crypto ACL simply point to a new access list that only defines your crypto traffic as follows:

access-list 100 permit ip 192.168.100.0 255.255.255.0 172.16.0.0 255.255.0.0

crypto map mapname 1 match address 100

As you can see, you just have to separate your nat 0 ACL from your crypto ACL, they don't have to be the same, and in your case, they can't be.

0 Helpful

li.simon
Level 1
Level 1
In response to gfullage

‎08-19-2003 04:03 PM

Thank you very much for your help. That resolved my problem to access VPN using PPTP. But for some reason, my VPN using IPSec did not work. I have followed this doc link

http://www.cisco.com/warp/public/110/38.html

to config my PIX-to-PIX VPN using IPSec.

Can you provide me some idea why my IPSec did not work by looking at the "sh ipsec sa" and "sh isakmp sa" below?

Thanks again.

pix# sh ipsec sa

interface: outside

Crypto map tag: mwavemap, local addr. 4.67.22.2

local ident (addr/mask/prot/port): (172.16.0.0/255.255.0.0/0/0)

remote ident (addr/mask/prot/port): (192.168.100.0/255.255.255.0/0/0)

current_peer: 65.197.235.2

PERMIT, flags={origin_is_acl,}

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 27, #pkts decrypt: 27, #pkts verify 27

#pkts compressed: 0, #pkts decompressed: 0

#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0

#send errors 0, #recv errors 0

local crypto endpt.: 4.67.22.2, remote crypto endpt.: 65.197.235.2

path mtu 1500, ipsec overhead 56, media mtu 1500

current outbound spi: b9dc9bd7

inbound esp sas:

spi: 0x67b1c19c(1739702684)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 1, crypto map: mwavemap

sa timing: remaining key lifetime (k/sec): (4607989/25998)

IV size: 8 bytes

replay detection support: Y

inbound ah sas:

inbound pcp sas:

outbound esp sas:

spi: 0xb9dc9bd7(3118242775)

transform: esp-des esp-md5-hmac ,

in use settings ={Tunnel, }

slot: 0, conn id: 2, crypto map: mwavemap

sa timing: remaining key lifetime (k/sec): (4608000/25899)

IV size: 8 bytes

replay detection support: Y

outbound ah sas:

outbound pcp sas:

pix# sh isakmp sa

Total : 1

Embryonic : 0

dst src state pending created

4.67.22.2 65.197.235.2 QM_IDLE 0 0

Auto output from local PIX

ISAKMP (0): deleting SA: src 65.197.235.2, dst 4.67.22.2

ISADB: reaper checking SA 0x83df8f00, conn_id = 0

ISADB: reaper checking SA 0x83dffbc0, conn_id = 0 DELETE IT!

VPN Peer: ISAKMP: Peer ip:65.197.235.2 Ref cnt decremented to:3 Total VPN Peers:

1

ISADB: reaper checking SA 0x83df8f00, conn_id = 0

Auto output from peer PIX:

ISAKMP (0): speaking to another IOS box!

return status is IKMP_NO_ERROR

crypto_isakmp_process_block: src 65.197.235.2, dest 4.67.22.2

OAK_MM exchange

ISAKMP (0): processing ID payload. message ID = 0

ISAKMP (0): processing HASH payload. message ID = 0

ISAKMP (0): SA has been authenticated

ISAKMP (0): ID payload

next-payload : 8

type : 1

protocol : 17

port : 500

length : 8

ISAKMP (0): Total payload length: 12

return status is IKMP_NO_ERROR

ISAKMP (0): deleting SA: src 65.197.235.2, dst 4.67.22.2

ISADB: reaper checking SA 0x83dffbc0, conn_id = 0

ISADB: reaper checking SA 0x83df8f00, conn_id = 0 DELETE IT!

VPN Peer: ISAKMP: Peer ip:65.197.235.2 Ref cnt decremented to:3 Total VPN Peers:

1

ISADB: reaper checking SA 0x83dffbc0, conn_id = 0

0 Helpful

gfullage
Cisco Employee
Cisco Employee
In response to li.simon

‎08-19-2003 04:22 PM

Going by your output the tunnel is up between the two PIX's. These lines:

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 27, #pkts decrypt: 27, #pkts verify 27

indictae that this PIX has received 27 packets over the tunnel and has decrypted them, but it has received no packets from the local network (172.16.0.0) to go to the remote network (192.168.100.0). Check the 172.16.0.0 network and make sure there's a route to the 192.168.100.0 network that points to this PIX. Also make sure this PIX has a route for the 192.168.100.0 network pointing out the outside interface (the default route will encompass this if there's nothing more specific).

Basically it looks like a routing problem, or you might still have your nat 0 ACL messed up, make sure it is correct and includes a line like the following:

access-list nonat permit ip 172.16.0.0 255.255.0.0 192.168.100.0 255.255.255.0

Pay particular attention to the subnet masks, it's easy to get those wrong and overlook them.

li.simon
Level 1
Level 1
In response to gfullage

‎08-20-2003 11:15 AM

Thank you Sir for your reply. Looks like I am almost there.

I have listed my config below and have following questons:

1.Check the 172.16.0.0 network and make sure there's a route to the 192.168.100.0 network that points to this PIX.

My answer: I believe I do. As you can see the config below, 172.16.1.1 is the inside interface IP address and is also my default gateway for all PCs at 172.16.0.0 network. So the route to the 192.168.100.0 network should be sent to default gateway on PIX inside (172.16.1.1).

2.Also make sure this PIX has a route for the 192.168.100.0 network pointing out the outside interface.

My answer: I am not sure if I have this route. Can you show me what is the command for this or how to check it? The only route command I have is "route outside 0 0 4.67.22.1 1".

3.According the output below, what kind of packets is that? Are they IKE/IPSec negotiation packets or real data packets? The 27 packets are auto showed up and I did not trigger VPN traffic.

#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0

#pkts decaps: 27, #pkts decrypt: 27, #pkts verify 27

4.How do you trigger the VPN traffic to test the VPN? What I did is to access web server at 192.168.100.0 network from PC at 172.16.0.0 network. Is this correct?

5. Below is my PIX config for IPSec: (PPTP is not listed b/c it is working.) Peer PIX has identical IPSec config except some IP is set for peer PIX.

interface ethernet0 100full

interface ethernet1 100full

ip address outside xx.xxx.xxx.2 255.255.255.0

ip address inside 172.16.1.1 255.255.0.0

nat (inside) 1 172.16.0.0 255.255.0.0

global (outside) 1 4.67.22.201-4.67.22.254 netmask 255.255.255.0

route outside 0 0 4.67.22.1 1

fragment chain 1 outside

fragment chain 1 inside

access-list acl_out permit udp any host 4.67.22.11 eq 53

access-list acl_out permit udp any host 4.67.22.12 eq 53

access-group acl_out in interface outside

access-list nonat permit ip 172.16.0.0 255.255.0.0 192.168.100.0 255.255.255.0

nat (inside) 0 access-list nonat

access-list 101 permit ip 172.16.0.0 255.255.0.0 192.168.100.0 255.255.255.0

sysopt connection permit-ipsec

crypto ipsec transform-set mwaveset esp-des esp-md5-hmac

crypto map mwavemap 1 ipsec-isakmp

crypto map mwavemap 1 match address 101

crypto map mwavemap 1 set peer 65.197.235.2

crypto map mwavemap 1 set transform-set mwaveset

crypto map mwavemap interface outside

isakmp enable outside

isakmp key ciscopix addressxxxx netmask xxxx

isakmp identity address

isakmp policy 1 authentication pre-share

isakmp policy 1 encryption des

isakmp policy 1 hash md5

isakmp policy 1 group 1

isakmp policy 1 lifetime 1000

0 Helpful
Customers Also Viewed These Support Documents