Go Back   Velocity Reviews > Newsgroups > Cisco
User Name
Password
Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

Reply

Cisco - FW upgrade caused PIX-to-PIX tunnel (shared-key) woes

 
Thread Tools Search this Thread
Old 12-31-2004, 04:20 AM   #1
Default FW upgrade caused PIX-to-PIX tunnel (shared-key) woes


Summary:
- I switched ISP's in one location
- I expanded that same network to a larger subnet
- I upgraded both PIX units to the 6.3(4) firmware
- Upgrading broke the vpn tunnel, I can't get it back
- I've tried all examples on CCO IPSec Product Support site w/no luck

So, I've been steadily working with a PIX 506 and PIX 515 configured
with VPN tunnel and remote VPN access. I know them well, but I can't
re-establish my site-to-site VPN tunnel for after a FW upgrade. Trying
for almost 2 days now. It was working prior to the upgrade, so I'm
sure I'm missing something stupid.

I had remote VPN access working in five minutes, but in two days, I
can't get the tunnel up. I know it has to be something simple I'm
missing. Here is my network config and my running configs:


Location 1:
PIX506
inside: 192.168.80.0/22
outside: 65.13.161.74/29
route: 65.13.161.73

Location 2:
PIX515
inside: 192.168.120.0/24
outside: 208.208.133.214/30
route: 208.208.133.213


My running configs:

=====================
Location1 :: PIX506
=====================
: Saved
: Written by enable_15 at 22:47:00.891 UTC Thu Dec 30 2004
PIX Version 6.3(4)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password mysecret encrypted
passwd mysecret encrypted
hostname pix506
domain-name ad.mydomain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list acl_in permit ip any any
access-list acl_out permit gre any any
access-list acl_out permit tcp any any eq pptp
access-list acl_out permit icmp any any
access-list acl_out permit udp host 65.13.161.74 any eq 1701
access-list acl_out permit ip 192.168.80.0 255.255.252.0 192.168.120.0
255.255.255.0
access-list acl_out permit ip 192.168.120.0 255.255.255.0 192.168.80.0
255.255.252.0
access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.120.0
255.255.255.0
access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.160.0
255.255.255.0
access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.150.0
255.255.255.0
access-list 506to515 permit ip 192.168.80.0 255.255.252.0 192.168.120.0
255.255.255.0
pager lines 50
logging on
logging trap informational
logging history debuggin
logging facility 22
logging host inside 192.168.80.4
no logging message 111005
mtu outside 1500
mtu inside 1500
ip address outside 65.13.161.74 255.255.255.248
ip address inside 192.168.80.1 255.255.252.0
ip audit info action alarm
ip audit attack action alarm
ip local pool ippool 192.168.160.1-192.168.160.254
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group acl_out in interface outside
access-group acl_in in interface inside
route outside 0.0.0.0 0.0.0.0 65.13.161.73 1
timeout xlate 3: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 TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
aaa-server Pepper protocol radius
aaa-server Pepper max-failed-attempts 3
aaa-server Pepper deadtime 10
aaa-server Pepper (inside) host 192.168.80.4 cisco timeout 5
http server enable
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt connection permit-pptp
sysopt connection permit-l2tp
crypto ipsec transform-set myset esp-des esp-sha-hmac
crypto map vpntunnel 20 ipsec-isakmp
crypto map vpntunnel 20 match address 506to515
crypto map vpntunnel 20 set peer 208.208.133.214
crypto map vpntunnel 20 set transform-set myset
isakmp enable outside
isakmp key mysecret address 208.208.133.214 netmask 255.255.255.255
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash sha
isakmp policy 10 group 1
isakmp policy 10 lifetime 86400
telnet 192.168.160.0 255.255.255.0 inside
telnet 192.168.80.0 255.255.252.0 inside
telnet timeout 30
ssh 192.168.80.0 255.255.252.0 inside
ssh timeout 60
console timeout 0
vpdn group 1 accept dialin pptp
vpdn group 1 ppp authentication mschap
vpdn group 1 ppp encryption mppe auto
vpdn group 1 client configuration address local ippool
vpdn group 1 client configuration dns 192.168.80.4
vpdn group 1 client configuration wins 192.168.80.4
vpdn group 1 client authentication aaa Pepper
vpdn group 1 pptp echo 60
vpdn enable outside
terminal width 80


=====================
Location1 :: PIX515
=====================
: Saved
: Written by enable_15 at 22:46:46.179 UTC Thu Dec 31 2004
PIX Version 6.3(4)
interface ethernet0 auto
interface ethernet1 auto
interface ethernet2 auto shutdown
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 intf2 security4
enable password mysecret encrypted
passwd mysecret encrypted
hostname pix515
domain-name ad.mydomain.com
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
fixup protocol http 80
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol sip 5060
fixup protocol sip udp 5060
fixup protocol skinny 2000
no fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
access-list acl_in permit ip any any
access-list acl_out permit gre any any
access-list acl_out permit tcp any any eq pptp
access-list acl_out permit icmp any any
access-list acl_out permit udp host 208.208.133.214 any eq 1701
access-list acl_out permit ip 192.168.80.0 255.255.252.0 192.168.120.0
255.255.255.0
access-list acl_out permit ip 192.168.120.0 255.255.255.0 192.168.80.0
255.255.252.0
access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.150.0
255.255.255.0
access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.80.0
255.255.252.0
access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.160.0
255.255.255.0
access-list 515to506 permit ip 192.168.120.0 255.255.255.0 192.168.80.0
255.255.252.0
pager lines 50
logging on
logging trap informational
logging history debugging
logging facility 22
logging host inside 192.168.120.5
no logging message 111005
mtu outside 1500
mtu inside 1500
mtu intf2 1500
ip address outside 208.208.133.214 255.255.255.252
ip address inside 192.168.120.1 255.255.255.0
ip address intf2 127.0.0.1 255.255.255.255
ip audit info action alarm
ip audit attack action alarm
ip local pool ippool 192.168.150.1-192.168.150.254
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list nonat
nat (inside) 1 0.0.0.0 0.0.0.0 0 0
access-group acl_out in interface outside
access-group acl_in in interface inside
route outside 0.0.0.0 0.0.0.0 208.208.133.213 1
timeout xlate 3: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 TACACS+ max-failed-attempts 3
aaa-server TACACS+ deadtime 10
aaa-server RADIUS protocol radius
aaa-server RADIUS max-failed-attempts 3
aaa-server RADIUS deadtime 10
aaa-server LOCAL protocol local
aaa-server Salt protocol radius
aaa-server Salt max-failed-attempts 3
aaa-server Salt deadtime 10
aaa-server Salt (inside) host 192.168.120.5 cisco timeout 5
http server enable
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
sysopt connection permit-pptp
sysopt connection permit-l2tp
crypto ipsec transform-set myset esp-des esp-sha-hmac
crypto map vpntunnel 20 ipsec-isakmp
crypto map vpntunnel 20 match address 515to506
crypto map vpntunnel 20 set peer 65.13.161.74
crypto map vpntunnel 20 set transform-set myset
isakmp enable outside
isakmp key mysecret address 65.13.161.74 netmask 255.255.255.255
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash sha
isakmp policy 10 group 1
isakmp policy 10 lifetime 86400
console timeout 0
vpdn group 1 accept dialin pptp
vpdn group 1 ppp authentication mschap
vpdn group 1 ppp encryption mppe auto
vpdn group 1 client configuration address local ippool
vpdn group 1 client configuration dns 192.168.120.5
vpdn group 1 client configuration wins 192.168.120.5
vpdn group 1 client authentication aaa Salt
vpdn group 1 pptp echo 60
vpdn enable outside
terminal width 80


*******************

What am I missing here? This seems so utterly obvious - I even dumbed
everything down to the most simple setup and it still won't work. I
tried to 'clear xlate', 'reload' and several other things to ensure
nothing is being cached.

Any help is GREATLY appreciated. I'm grinding teeth. The PIX
firewalls are nothing like the UBR series routers
TIA (and sorry for the long ass post, RC's take up a lot of room )



shifty
  Reply With Quote
Old 12-31-2004, 07:35 AM   #2
Walter Roberson
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
In article <. com>,
shifty <> wrote:
:Summary:
:- I upgraded both PIX units to the 6.3(4) firmware
:- Upgrading broke the vpn tunnel, I can't get it back

:Location1 :: PIX506

:crypto map vpntunnel 20 ipsec-isakmp
:crypto map vpntunnel 20 match address 506to515
:crypto map vpntunnel 20 set peer 208.208.133.214
:crypto map vpntunnel 20 set transform-set myset

You haven't applied that crypto map to an interface.

crypto map vpntunnel interface outside


:Location1 :: PIX515

:crypto map vpntunnel 20 ipsec-isakmp
:crypto map vpntunnel 20 match address 515to506
:crypto map vpntunnel 20 set peer 65.13.161.74
:crypto map vpntunnel 20 set transform-set myset

Same problem. Same solution.


Note for future reference:

I didn't carefully look over the configurations and have my eagle
eyes pick the problem out: I ran the configurations through the
Cisco Output Interpreter. As you upgraded to 6.3(4), you almost
certainly have CCO access. http://www.cisco.com/tac and
log in and nearish the upper right click on Output Interpreter.
Paste in your configuration and let cisco's tools automatically
analyze it. It doesn't always find everything, and sometimes
it makes mistakes, but often can point the way through problems,
and often has excellent suggestions on how security could be
improved.
--
Caution: A subset of the statements in this message may be
tautologically true.


Walter Roberson
  Reply With Quote
Old 12-31-2004, 07:50 AM   #3
shifty
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
In the words of George Washington, " I cannot tell a lie". I acquired
6.3(4) by some nefarious means.

Seriously though, I picked the newer firmware up from a friend and
don't have CCO access. I was slightly aware of something like the COI
you speak of, but ... most of them were pay devices and I usually
choose to learn on my own without taking the "easy way out". I hope
that's more commendable than my actions used when obtaining the
firmware.


I tried the fix you suggested - to no avail I admit it was good
advice. I don't suppose you could edit the two RC's and try to run it
through the COI again? I'd really appreciate it.



shifty
  Reply With Quote
Old 12-31-2004, 10:12 AM   #4
Walter Roberson
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
In article <. com>,
shifty <> wrote:

:Location1 :: PIX506

:access-list acl_in permit ip any any

You can drop that and the associated access-group command, as
the default is to permit any ip from a higher security to a lower
security interface. It shouldn't hurt to have it, though.


:access-list acl_out permit gre any any
:access-list acl_out permit tcp any any eq pptp
:access-list acl_out permit icmp any any
:access-list acl_out permit udp host 65.13.161.74 any eq 1701

That host is the same IP as your outside interface, and you have
acl_out applied 'in' the outside interface. There will never be
an occasion on which that line matches. The outside interface IP address
is normally only used to send packets that originate at the PIX out to
the outside; a packet that originated at the PIX being sent to the
inside would have an IP which was the inside interface IP. [My
"normally" is modified by the fact that you are nat'ing to 'interface',
but still that NAT would only apply on sending packets out.] Perhaps
you wanted to use the IP of the remote PIX there?

:access-list acl_out permit ip 192.168.80.0 255.255.252.0 192.168.120.0 255.255.255.0

Similar to the above situation: 192.168.80 is inside, and this ACL would
only match packets coming from the outside that had that IP range
and were destined for an IP address range that doesn't exist on the
inside. You should probably drop this line.

:access-list acl_out permit ip 192.168.120.0 255.255.255.0 192.168.80.0 255.255.252.0

192.168.120/24 is on the other side of the tunnel, and 192.168.80/22
is on the inside, so that ACL is not wrong. On the other hand,
you have sysopt connection permit-ipsec which bypasses ACL processing
for incoming ipsec packets, so this line is not going to be used.
And if any spoofed packets from the outside come along with that
IP address range, the PIX is going to drop the packet anyhow on
the grounds that it matches the crypto ACL but the packet isn't protected
by iPSec... so this line doesn't even permit IP spoofing that it might
otherwise appear to permit. You don't need this line as long as you
have the sysopt in effect.

:access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.120.0 255.255.255.0
:access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.160.0 255.255.255.0
:access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.150.0 255.255.255.0

:access-list 506to515 permit ip 192.168.80.0 255.255.252.0 192.168.120.0 255.255.255.0

:ip address outside 65.13.161.74 255.255.255.248
:ip address inside 192.168.80.1 255.255.252.0

:global (outside) 1 interface
:nat (inside) 0 access-list nonat
:nat (inside) 1 0.0.0.0 0.0.0.0 0 0
:access-group acl_out in interface outside
;access-group acl_in in interface inside

:sysopt connection permit-ipsec

:crypto map vpntunnel 20 ipsec-isakmp
:crypto map vpntunnel 20 match address 506to515
:crypto map vpntunnel 20 set peer 208.208.133.214
:crypto map vpntunnel 20 set transform-set myset

:isakmp key mysecret address 208.208.133.214 netmask 255.255.255.255

:isakmp policy 10 authentication pre-share
:isakmp policy 10 encryption des

You appear to be in the USA; you can probably get a free 3DES/AES license
unless you are on the proscribed persons list. I see that your other
IP block is apparently assigned to 'Arab Banking Corporation',
but with a US address: even if one of the banned countries is involved,
my -understanding- [perhaps wrong] is that the banned countries list
only applies to exported goods, not to goods used within the USA,
and the only list that applies within the US itself is the proscribed
persons list.

Mind you, to apply for a 3DES/AES license, you would have to give
the system serial number, and if you bought the equipment used,
Cisco wouldn't want to provide a key.


:Location1 :: PIX515

:access-list acl_in permit ip any any

Redundant, as noted above.

:access-list acl_out permit gre any any
:access-list acl_out permit tcp any any eq pptp
:access-list acl_out permit icmp any any
:access-list acl_out permit udp host 208.208.133.214 any eq 1701

Probably wrong IP address, as noted above.

:access-list acl_out permit ip 192.168.80.0 255.255.252.0 192.168.120.0 255.255.255.0

As noted above, not a useful line while the sysopt is in effect.

:access-list acl_out permit ip 192.168.120.0 255.255.255.0 192.168.80.0 255.255.252.0

As noted above, not a useful line considering the source is inside.

:access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.150.0 255.255.255.0
:access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.80.0 255.255.252.0
:access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.160.0 255.255.255.0

:access-list 515to506 permit ip 192.168.120.0 255.255.255.0 192.168.80.0 255.255.252.0

:ip address outside 208.208.133.214 255.255.255.252
:ip address inside 192.168.120.1 255.255.255.0

:global (outside) 1 interface
:nat (inside) 0 access-list nonat
:nat (inside) 1 0.0.0.0 0.0.0.0 0 0
:access-group acl_out in interface outside
:access-group acl_in in interface inside

:sysopt connection permit-ipsec

:crypto map vpntunnel 20 ipsec-isakmp
:crypto map vpntunnel 20 match address 515to506
:crypto map vpntunnel 20 set peer 65.13.161.74
:crypto map vpntunnel 20 set transform-set myset

:isakmp key mysecret address 65.13.161.74 netmask 255.255.255.255


None of the above-noted issues would prevent the tunnel from
working.
--
Rome was built one paycheck at a time. -- Walter Roberson


Walter Roberson
  Reply With Quote
Old 12-31-2004, 10:29 AM   #5
Walter Roberson
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
In article <. com>,
shifty <> wrote:

:Location1 :: PIX506

:access-list acl_out permit gre any any

You appear to have that statement in support of your pptp dialin,
but it isn't going to do you any good. ACLs only affect traffic
-through- the PIX, not traffic -to- the PIX such as would be the
case when you are using the PIX as the pptp endpoint. The statement
also isn't going to support pptp to hosts inside the firewall,
because you are using PAT (port address translation) to translate
all inside addresses to the outside interface IP, but GRE cannot
be PAT'd because GRE does not have ports. In order to use GRE in
conjunction with PAT'ing to the outside IP, you would have to
use the esp-like fixup, which cannot be used when you have a crypto
map applied to the outside interface.

I would suggest removing this line.

:access-list acl_out permit tcp any any eq pptp

Similarily, this isn't going to help your pptp dialin to the PIX
itself. The TCP pptp port -is- subject to PAT, but you haven't
defined any static port translation to convey the port to a
particular inside host so the statement isn't useful for forming
new pptp connections to inside hosts. It also isn't useful for
return traffic for outgoing connections that happen to use the pptp
port, as the PIX would automatically open a pinhole for the return
traffic.

I would suggest removing this line.


:access-list acl_out permit icmp any any

That's not secure, as you are allowing in host redirects and
network redirects; someone outside could tell one of your
systems to connect to a system other than the one it should really
connect to.

:access-list acl_out permit udp host 65.13.161.74 any eq 1701

1701 would be for L2TP support, but you haven't defined any
L2TP configuration. As I noted in a previous posting, the IP address
is wrong. I would suggest removing this line.

--
Entropy is the logarithm of probability -- Boltzmann


Walter Roberson
  Reply With Quote
Old 12-31-2004, 01:19 PM   #6
shifty
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
Walter Roberson wrote:
> In article <. com>,
> shifty <> wrote:
>
> 1701 would be for L2TP support, but you haven't defined any
> L2TP configuration. As I noted in a previous posting, the IP address
> is wrong. I would suggest removing this line.
>


Thanks. I haven't as of yet - I had it configured previously. I'm
starting with (basically) a fresh config.

In moving to my new building, they have set me up with some Netopia
router. My only last suspicion is that maybe they are blocking IPSec
traffic....the configuration seems perfectly fine to me. I can't find
a single reason why the tunnel should not be working.



shifty
  Reply With Quote
Old 12-31-2004, 01:41 PM   #7
John Smith
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
this may not make a difference now, but did you atleast save your configs
BEFORE you upgraded the pix'es? and what version did you upgrade from?




On Thu, 30 Dec 2004 20:20:28 -0800, shifty wrote:

> Summary:
> - I switched ISP's in one location
> - I expanded that same network to a larger subnet
> - I upgraded both PIX units to the 6.3(4) firmware
> - Upgrading broke the vpn tunnel, I can't get it back
> - I've tried all examples on CCO IPSec Product Support site w/no luck
>
> So, I've been steadily working with a PIX 506 and PIX 515 configured
> with VPN tunnel and remote VPN access. I know them well, but I can't
> re-establish my site-to-site VPN tunnel for after a FW upgrade. Trying
> for almost 2 days now. It was working prior to the upgrade, so I'm
> sure I'm missing something stupid.
>
> I had remote VPN access working in five minutes, but in two days, I
> can't get the tunnel up. I know it has to be something simple I'm
> missing. Here is my network config and my running configs:
>
>
> Location 1:
> PIX506
> inside: 192.168.80.0/22
> outside: 65.13.161.74/29
> route: 65.13.161.73
>
> Location 2:
> PIX515
> inside: 192.168.120.0/24
> outside: 208.208.133.214/30
> route: 208.208.133.213
>
>
> My running configs:
>
> =====================
> Location1 :: PIX506
> =====================
> : Saved
> : Written by enable_15 at 22:47:00.891 UTC Thu Dec 30 2004
> PIX Version 6.3(4)
> interface ethernet0 auto
> interface ethernet1 auto
> nameif ethernet0 outside security0
> nameif ethernet1 inside security100
> enable password mysecret encrypted
> passwd mysecret encrypted
> hostname pix506
> domain-name ad.mydomain.com
> fixup protocol dns maximum-length 512
> fixup protocol ftp 21
> fixup protocol h323 h225 1720
> fixup protocol h323 ras 1718-1719
> fixup protocol http 80
> fixup protocol rsh 514
> fixup protocol rtsp 554
> fixup protocol sip 5060
> fixup protocol sip udp 5060
> fixup protocol skinny 2000
> no fixup protocol smtp 25
> fixup protocol sqlnet 1521
> fixup protocol tftp 69
> names
> access-list acl_in permit ip any any
> access-list acl_out permit gre any any
> access-list acl_out permit tcp any any eq pptp
> access-list acl_out permit icmp any any
> access-list acl_out permit udp host 65.13.161.74 any eq 1701
> access-list acl_out permit ip 192.168.80.0 255.255.252.0 192.168.120.0
> 255.255.255.0
> access-list acl_out permit ip 192.168.120.0 255.255.255.0 192.168.80.0
> 255.255.252.0
> access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.120.0
> 255.255.255.0
> access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.160.0
> 255.255.255.0
> access-list nonat permit ip 192.168.80.0 255.255.252.0 192.168.150.0
> 255.255.255.0
> access-list 506to515 permit ip 192.168.80.0 255.255.252.0 192.168.120.0
> 255.255.255.0
> pager lines 50
> logging on
> logging trap informational
> logging history debuggin
> logging facility 22
> logging host inside 192.168.80.4
> no logging message 111005
> mtu outside 1500
> mtu inside 1500
> ip address outside 65.13.161.74 255.255.255.248
> ip address inside 192.168.80.1 255.255.252.0
> ip audit info action alarm
> ip audit attack action alarm
> ip local pool ippool 192.168.160.1-192.168.160.254
> pdm history enable
> arp timeout 14400
> global (outside) 1 interface
> nat (inside) 0 access-list nonat
> nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> access-group acl_out in interface outside
> access-group acl_in in interface inside
> route outside 0.0.0.0 0.0.0.0 65.13.161.73 1
> timeout xlate 3: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 TACACS+ max-failed-attempts 3
> aaa-server TACACS+ deadtime 10
> aaa-server RADIUS protocol radius
> aaa-server RADIUS max-failed-attempts 3
> aaa-server RADIUS deadtime 10
> aaa-server LOCAL protocol local
> aaa-server Pepper protocol radius
> aaa-server Pepper max-failed-attempts 3
> aaa-server Pepper deadtime 10
> aaa-server Pepper (inside) host 192.168.80.4 cisco timeout 5
> http server enable
> no snmp-server location
> no snmp-server contact
> snmp-server community public
> no snmp-server enable traps
> floodguard enable
> sysopt connection permit-ipsec
> sysopt connection permit-pptp
> sysopt connection permit-l2tp
> crypto ipsec transform-set myset esp-des esp-sha-hmac
> crypto map vpntunnel 20 ipsec-isakmp
> crypto map vpntunnel 20 match address 506to515
> crypto map vpntunnel 20 set peer 208.208.133.214
> crypto map vpntunnel 20 set transform-set myset
> isakmp enable outside
> isakmp key mysecret address 208.208.133.214 netmask 255.255.255.255
> isakmp policy 10 authentication pre-share
> isakmp policy 10 encryption des
> isakmp policy 10 hash sha
> isakmp policy 10 group 1
> isakmp policy 10 lifetime 86400
> telnet 192.168.160.0 255.255.255.0 inside
> telnet 192.168.80.0 255.255.252.0 inside
> telnet timeout 30
> ssh 192.168.80.0 255.255.252.0 inside
> ssh timeout 60
> console timeout 0
> vpdn group 1 accept dialin pptp
> vpdn group 1 ppp authentication mschap
> vpdn group 1 ppp encryption mppe auto
> vpdn group 1 client configuration address local ippool
> vpdn group 1 client configuration dns 192.168.80.4
> vpdn group 1 client configuration wins 192.168.80.4
> vpdn group 1 client authentication aaa Pepper
> vpdn group 1 pptp echo 60
> vpdn enable outside
> terminal width 80
>
>
> =====================
> Location1 :: PIX515
> =====================
> : Saved
> : Written by enable_15 at 22:46:46.179 UTC Thu Dec 31 2004
> PIX Version 6.3(4)
> interface ethernet0 auto
> interface ethernet1 auto
> interface ethernet2 auto shutdown
> nameif ethernet0 outside security0
> nameif ethernet1 inside security100
> nameif ethernet2 intf2 security4
> enable password mysecret encrypted
> passwd mysecret encrypted
> hostname pix515
> domain-name ad.mydomain.com
> fixup protocol dns maximum-length 512
> fixup protocol ftp 21
> fixup protocol h323 h225 1720
> fixup protocol h323 ras 1718-1719
> fixup protocol http 80
> fixup protocol rsh 514
> fixup protocol rtsp 554
> fixup protocol sip 5060
> fixup protocol sip udp 5060
> fixup protocol skinny 2000
> no fixup protocol smtp 25
> fixup protocol sqlnet 1521
> fixup protocol tftp 69
> names
> access-list acl_in permit ip any any
> access-list acl_out permit gre any any
> access-list acl_out permit tcp any any eq pptp
> access-list acl_out permit icmp any any
> access-list acl_out permit udp host 208.208.133.214 any eq 1701
> access-list acl_out permit ip 192.168.80.0 255.255.252.0 192.168.120.0
> 255.255.255.0
> access-list acl_out permit ip 192.168.120.0 255.255.255.0 192.168.80.0
> 255.255.252.0
> access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.150.0
> 255.255.255.0
> access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.80.0
> 255.255.252.0
> access-list nonat permit ip 192.168.120.0 255.255.255.0 192.168.160.0
> 255.255.255.0
> access-list 515to506 permit ip 192.168.120.0 255.255.255.0 192.168.80.0
> 255.255.252.0
> pager lines 50
> logging on
> logging trap informational
> logging history debugging
> logging facility 22
> logging host inside 192.168.120.5
> no logging message 111005
> mtu outside 1500
> mtu inside 1500
> mtu intf2 1500
> ip address outside 208.208.133.214 255.255.255.252
> ip address inside 192.168.120.1 255.255.255.0
> ip address intf2 127.0.0.1 255.255.255.255
> ip audit info action alarm
> ip audit attack action alarm
> ip local pool ippool 192.168.150.1-192.168.150.254
> pdm history enable
> arp timeout 14400
> global (outside) 1 interface
> nat (inside) 0 access-list nonat
> nat (inside) 1 0.0.0.0 0.0.0.0 0 0
> access-group acl_out in interface outside
> access-group acl_in in interface inside
> route outside 0.0.0.0 0.0.0.0 208.208.133.213 1
> timeout xlate 3: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 TACACS+ max-failed-attempts 3
> aaa-server TACACS+ deadtime 10
> aaa-server RADIUS protocol radius
> aaa-server RADIUS max-failed-attempts 3
> aaa-server RADIUS deadtime 10
> aaa-server LOCAL protocol local
> aaa-server Salt protocol radius
> aaa-server Salt max-failed-attempts 3
> aaa-server Salt deadtime 10
> aaa-server Salt (inside) host 192.168.120.5 cisco timeout 5
> http server enable
> no snmp-server location
> no snmp-server contact
> snmp-server community public
> no snmp-server enable traps
> floodguard enable
> sysopt connection permit-ipsec
> sysopt connection permit-pptp
> sysopt connection permit-l2tp
> crypto ipsec transform-set myset esp-des esp-sha-hmac
> crypto map vpntunnel 20 ipsec-isakmp
> crypto map vpntunnel 20 match address 515to506
> crypto map vpntunnel 20 set peer 65.13.161.74
> crypto map vpntunnel 20 set transform-set myset
> isakmp enable outside
> isakmp key mysecret address 65.13.161.74 netmask 255.255.255.255
> isakmp policy 10 authentication pre-share
> isakmp policy 10 encryption des
> isakmp policy 10 hash sha
> isakmp policy 10 group 1
> isakmp policy 10 lifetime 86400
> console timeout 0
> vpdn group 1 accept dialin pptp
> vpdn group 1 ppp authentication mschap
> vpdn group 1 ppp encryption mppe auto
> vpdn group 1 client configuration address local ippool
> vpdn group 1 client configuration dns 192.168.120.5
> vpdn group 1 client configuration wins 192.168.120.5
> vpdn group 1 client authentication aaa Salt
> vpdn group 1 pptp echo 60
> vpdn enable outside
> terminal width 80
>
>
> *******************
>
> What am I missing here? This seems so utterly obvious - I even dumbed
> everything down to the most simple setup and it still won't work. I
> tried to 'clear xlate', 'reload' and several other things to ensure
> nothing is being cached.
>
> Any help is GREATLY appreciated. I'm grinding teeth. The PIX
> firewalls are nothing like the UBR series routers
> TIA (and sorry for the long ass post, RC's take up a lot of room )




John Smith
  Reply With Quote
Old 12-31-2004, 01:58 PM   #8
shifty
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
I upgraded from 6.1(1) to 6.3(4). I should have included that in the
original post.

So many significant changes have occured in 6.2 and 6.3 that it was
silly to upgrade to 6.2. Likewise, several things were added and/or
deprecated from previous upgrades and ... there were also lots of dead
commands.

I have tried to return to the original configs on both firewalls to no
avail. I had two complains from the PIX when upgrading...could they be
related?:

Gripe #1:
..The sysopt route dnat option has been deprecated
Config Error -- no sysopt route dnat (I was using this previously)
..
Config Failed

Gripe #2:
Cannot select private key


Fix for Gripe #1:
Use the sysopt command to add or remove any sysopt command and 'wr m'.
This forced the new configuration in place (I think I used 'no sysopt
http-auth' or something and it cleared up immediately).

Fix for Gripe #2:
Type: ca zeroize rsa
Type: ca gen rsa key 1024
Type: ca save all (basically, I generated a new key because the old
one could not be read)


Would the deprecation of sysopt route dnat or my problems with the CA
cause the tunnel to fail?



shifty
  Reply With Quote
Old 12-31-2004, 02:13 PM   #9
shifty
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
Question:

I'm stepping out on a limb here, but ... In the new location, is it
possible that they're blocking IPSec traffic?

I ask because I've never encountered one of these "Netopia" routers
they're using as our gateway, so ... It's an large communications
provider, but I wouldn't put it past them to do something stupid. They
assured me all ports would be open - but they never said anything about
whether any protocols would be blocked.

Would anything else be failing if IPSec was down (other than the
tunnel?)

Is there any way to easily troubleshoot using something other than
IPSec that would have a lower likelihood of being blocked?

Just some other thoughts ... I just cannot fathom why it's not working.
This is really frustrating :\



shifty
  Reply With Quote
Old 12-31-2004, 06:29 PM   #10
Walter Roberson
 
Posts: n/a
Default Re: FW upgrade caused PIX-to-PIX tunnel (shared-key) woes
In article < .com>,
shifty <> wrote:
:I'm stepping out on a limb here, but ... In the new location, is it
ossible that they're blocking IPSec traffic?

Yes, it is possible.

I would suggest putting in

isakmp nat-traversal 20

in both sides. That will allow the devices to communicate by udp
without AH or ESP packets.
--
Warhol's Law: every Usenet user is entitled to his or her very own
fifteen minutes of flame -- The Squoire



Walter Roberson
  Reply With Quote
Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
VRF GRE Tunnel over another VRF network ngurjar Software 0 10-11-2008 05:15 AM
Re: 120 Gig HD Limit and Win XP upgrade Bill Eitner A+ Certification 0 07-19-2008 03:34 AM
Re: hypothetical upgrade situation hootnholler A+ Certification 0 11-11-2003 01:38 AM




SEO by vBSEO 3.3.2 ©2009, Crawlability, Inc.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46