PIX VPN -- Am I Missing Something?

Trying to bring up a VPN between two PIX 525's in my lab. Currently topology looks like this

(INSIDE NETWORK)---PIX1 --- Router --- PIX2 --- (INSIDE NETWORK)

I am not the most familiar person with PIX, but I think I got everything configured correctly. I can ping the outside interfaces of the pix from the other pix. But when trying to execute a ping from the pix to the inside network of the other PIX i just get ????? so its not bringing up a VPN tunnel. I'm running OS Ver. 8.0(4). And this is my config... Did i miss anything?

interface Ethernet0
 nameif outside
 security-level 0
 ip address 10.10.200.1 255.255.255.0 
!             
interface Ethernet4
 nameif inside
 security-level 100
 ip address 10.10.10.1 255.255.255.0 
!             
ftp mode passive
access-list 101 extended permit ip 10.10.10.0 255.255.255.0 10.10.100.0 255.255.255.0 
access-list NoNAT extended permit ip 10.10.10.0 255.255.255.0 10.10.100.0 255.255.255.0 
pager lines 24
mtu outside 1500
mtu inside 1500
no failover   
icmp unreachable rate-limit 1 burst-size 1
no asdm history enable
arp timeout 14400
nat (inside) 0 access-list NoNAT
route outside 0.0.0.0 0.0.0.0 10.10.200.2 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 icmp 0:00:02
timeout sunrpc 0:10:00 h323 0:05:00 h225 1:00:00 mgcp 0:05:00 mgcp-pat 0:05:00
timeout sip 0:30:00 sip_media 0:02:00 sip-invite 0:03:00 sip-disconnect 0:02:00
timeout sip-provisional-media 0:02:00 uauth 0:05:00 absolute
dynamic-access-policy-record DfltAccessPolicy
no snmp-server location
no snmp-server contact
snmp-server enable traps snmp authentication linkup linkdown coldstart
crypto ipsec transform-set VPN esp-des esp-md5-hmac 
crypto ipsec security-association lifetime seconds 28800
crypto ipsec security-association lifetime kilobytes 4608000
crypto dynamic-map CRYPTO_DYNAMIC_MAP 1 match address 101
crypto dynamic-map CRYPTO_DYNAMIC_MAP 1 set pfs 
crypto dynamic-map CRYPTO_DYNAMIC_MAP 1 set peer 192.168.1.1 
crypto dynamic-map CRYPTO_DYNAMIC_MAP 1 set transform-set VPN
crypto dynamic-map CRYPTO_DYNAMIC_MAP 1 set security-association lifetime seconds 28800
crypto dynamic-map CRYPTO_DYNAMIC_MAP 1 set security-association lifetime kilobytes 4608000
crypto map CRYPTOMAP 1 ipsec-isakmp dynamic CRYPTO_DYNAMIC_MAP
crypto map CRYPTOMAP interface outside
crypto isakmp enable outside
crypto isakmp policy 1
 authentication pre-share
 encryption des
 hash md5     
 group 1      
 lifetime 1000
telnet timeout 5
ssh timeout 5 
console timeout 0
threat-detection basic-threat
threat-detection statistics access-list
no threat-detection statistics tcp-intercept
tunnel-group 192.168.1.1 type ipsec-l2l
tunnel-group 192.168.1.1 ipsec-attributes
 pre-shared-key *

Find more posts tagged with

Comments

millworx

phoeneous wrote: »

Is the "inside network" a local interface of pix2 or is it connected to a switch?

And which config did you paste, pix1 or pix2?

The inside network is a switch connected to the PIX and this is PIX1, the PIX2 configuration is almost identical except the peer address, and the access list which specifies the interesting traffic from its internal network of PIX2 and the destination being the internal of PIX1

ConstantlyLearning

I'll come back to this tomorrow but generally you'll test the VPN by sending traffic from the INSIDE of one of the PIX's to the INSIDE of the other PIX. Not from the PIX itself.

When setting up this type of lab for a site to site VPN I'll usually do something like the following:

Physical setup of 2 PIX's with a router in the middle as the 'Internet'.
Router has IP addresses on two interfaces to be the DG's for each of the PIX's.
Configure each PIX; outside interface address on same subnet as one of the router interfaces, inside interface address as whatever, PAT, DG etc.
Confirm connectivity from PIX to PIX and from the inside of each pix to the outside of the other PIX.

Configure the VPN:
isakmp policy
transform set
interesting traffic (ACL for traffic to be encrypted i.e sent over the tunnel)
nat exemption
crypto map
etc.

Hope that helps for now.

EDIT: Your config looks like it's for a remote access VPN and not a site to site VPN which I think it what you want?

millworx

ConstantlyLearning wrote: »

I'll come back to this tomorrow but generally you'll test the VPN by sending traffic from the INSIDE of one of the PIX's to the INSIDE of the other PIX. Not from the PIX itself.

When setting up this type of lab for a site to site VPN I'll usually do something like the following:

Physical setup of 2 PIX's with a router in the middle as the 'Internet'.
Router has IP addresses on two interfaces to be the DG's for each of the PIX's.
Configure each PIX; outside interface address on same subnet as one of the router interfaces, inside interface address as whatever, PAT, DG etc.
Confirm connectivity from PIX to PIX and from the inside of each pix to the outside of the other PIX.

Configure the VPN:
isakmp policy
transform set
interesting traffic (ACL for traffic to be encrypted i.e sent over the tunnel)
nat exemption
crypto map
etc.

Hope that helps for now.

EDIT: Your config looks like it's for a remote access VPN and not a site to site VPN which I think it what you want?

Yes its for site to site. You know I connected my comptuer via cloud in GNS3 and have attempted to ping across the VPN with no success. My laptop can ping the inside interface of the pic but no further.

Ahriakin

Yup as was stated you've tried to setup an RA VPN, with some L2L elements (that ultimately aren't called in your crypto map). Which tbh is much more of a pain in the ass than a std. L2L.Remove your dynamic config and start again taking each of Constantlylearnings's steps in turn

e.g.
crypto map CRYPTOMAP 10 set transform set xxxxx
crypto map CRYPTOMAP 10 set peer xxxxx
crypto map CRYPTOMAP 10 match address xxxxx

Do you have an outside ACL (not referenced above)? if so are you permitting your tunneled connections (or do you have sysopt set to bypass for VPN traffic (do a sh run all sysopt to verify).

Also never rely on testing with the IPs of your PIX/ASA itself. You can bring up the tunnel but the device will never reply to a ping to one of it's own interfaces that originates on another DMZ (though you could run a capture on the OUTSIDE interface on the target ASA just to make sure the packets are getting there).

Another handy way to bring up a tunnel for testing is run a packet-tracer on one side that matches an element of your interesting traffic, again nothing will actually pass but it is enough to initiate. The other advantage of course is you get some good debug info from the command itself if something goes wrong.

networker050184

phoeneous wrote: »

And I'm sure you've already done it but don't forget to set default-gateway on the switches. I've done that a few times and was wondering why internal hosts werent replying to pings.

The default-gateway on the switch isn't going to have an effect on host traffic.

Now if you are using a L3 switch you need a route, but not a default-gateway configuration.

ConstantlyLearning

networker050184 wrote: »

The default-gateway on the switch isn't going to have an effect on host traffic.

Now if you are using a L3 switch you need a route, but not a default-gateway configuration.

Yeah, no need to go messing with the switches.

ConstantlyLearning

phoeneous wrote: »

Interesting. I opened a case with TAC because after I setup ra vpn to branch office I wasnt able to ping any hosts past the switch. The tac engineer saw that I didnt have default gateway on the switch that all hosts were connected to. After we added that command icmp replies went through.

I'd guess that something else was changed as well.

The ip default-gateway command on a Layer 2 switch isn't required in that situation.

mikej412

phoeneous wrote: »

I just labbed this up in packet tracer and I wasnt able to ping from 192.168.1.3/24 to 192.168.2.3/24 until I set ip default-gateway on both switches.

Sounds like a packet tracer software bug.

You only need the default gateway (and switch admin IP) set if you're pinging from or to the switch using their admin ip as a source or destination.

Hosts plugged into dumb layer 2 switches and idiot hubs were still able to communicate over layer 3 networks long before the rise of smart managed switches.

With an admin IP and a default gateway set, the switch gets some host functions that can help you trouble shoot network issues and do remote admin on the switch. But the lack of a default gateway setting on a layer 2 switch has no effect on the functioning of the layer 3 network around it as long as it does it's layer 2 job.

Someone using real hardware to study would have just kicked packet tracer's (and the person who used it) butt if this had been a job interview.

Sometimes with packet tracer you do the correct configuration and you get an unexpected result. You can either save your work, shut down, and restart packet tracer. Then try it again. Or you can do a random command, which could force packer tracer to reevaluate it's network -- and you just "learned" the default gateway setting on layer 2 switch affects the rest of the layer 3 network.

When you pinged, were all the packet tracer link lights green showing that STP had converged -- or had you configured spanning-tree portfast?