PIX to PIX VPN problem
John Scholvin
I am trying to establish a VPN tunnel between 2 PIX 506E's. This is, for
now, as straightforward a setup as there could be:
private LAN 1 --- PIX 1 ----- internet ----- PIX 2 ----- private LAN 2
Each pix's public IP is pingable from the other side.
I've followed the basic setup I found at
http://www.cisco.com/en/US/customer/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094761.shtml.
The problem is that the pixen don't seem to even want to get to phase 1
negotiations. "show isakmp sa" returns 0 associations on both sides.
I've enabled all crypto and access-list debugging on both sides, and there
is no output. It's like they just don't even want to talk to each other, or
know that they should, or tell me why. Obviously it's very frustrating.
What's the best way to proceed on debugging this problem from here? Does
this sound familiar to anyone?
--
John Scholvin -- jo...@scholvin.com -- an E7b5#9 man in an F major world
rave
First of all you have to enable logging on the PIX to get some debugs.
Check the log settings on the PIX whether you have enabled logging
level as debugging and also if you are connected via a telnet session
to the PIX then you have to type in "term mon" to see the debugs in the
terminal session.
You will definitely get some debugs as to why it if failing.
Even if phase 1 is not coming u-p then it is basically routing issue ot
nat 0 issue, check into that.
Regards,
Rave
John Scholvin
rave <puneet.a...@gmail.com> wrote:
>First of all you have to enable logging on the PIX to get some debugs.
>Check the log settings on the PIX whether you have enabled logging
>level as debugging and also if you are connected via a telnet session
>to the PIX then you have to type in "term mon" to see the debugs in the
>terminal session.
Been there, did that, still no output.
Is it possible that my problem is that I am accessing the PIX via ssh into
the outside interface? I am seeing somewhat conflicting data on various
websites about the ability to see debug info in ssh sessions. Do I have to
access the PIX via the serial cable on the back to see what's going on in
there? Do I have to use telnet into the inside interface?
Thanks,
John
Walter Roberson
John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
>Is it possible that my problem is that I am accessing the PIX via ssh into
>the outside interface? I am seeing somewhat conflicting data on various
>websites about the ability to see debug info in ssh sessions. Do I have to
>access the PIX via the serial cable on the back to see what's going on in
>there? Do I have to use telnet into the inside interface?
No, when you are ssh'd in and you use 'debug' commands, the output goes
to your ssh session. You might possibly need to adjust the
"logging monitor" level but I don't think so.
To get the regular event log to your ssh session, you would want
to adjust the "logging monitor" level and you would "terminal monitor".
Walter Roberson
John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
>I am trying to establish a VPN tunnel between 2 PIX 506E's.
>The problem is that the pixen don't seem to even want to get to phase 1
>negotiations. "show isakmp sa" returns 0 associations on both sides.
>I've enabled all crypto and access-list debugging on both sides, and there
>is no output. It's like they just don't even want to talk to each other, or
>know that they should, or tell me why. Obviously it's very frustrating.
>What's the best way to proceed on debugging this problem from here? Does
>this sound familiar to anyone?
I suggest "debug packet outside", or "capture" if you have more
traffic than debug packet is convenient for.
When you are constructing the ACL for a capture command, assume that
it will *not* automatically be "read backwards" like all other ACLs
are:
access-list CapACL permit ip host REMOTEPIX host LOCALPIX
access-list CapACL permit ip host LOCALPIX host REMOTEPIX
access-list CapACL permit ip REMOTENET REMOTEMASK LOCALNET LOCALMASK
access-list CapACL permit ip LOCALNET LOCALMASK REMOTENET REMOTEMASK
John Scholvin
Walter Roberson <robe...@hushmail.com> wrote:
>No, when you are ssh'd in and you use 'debug' commands, the output goes
>to your ssh session. You might possibly need to adjust the
>"logging monitor" level but I don't think so.
Weird...this never worked for me. I tried turning on all kinds of debug and
saw none of it in my ssh session. But I did manage to use "logging console"
to see some debug output on the console port, so I made progress on my problem.
I'll have to come back to this after I solve the more pressing crisis...
Thanks,
john
John Scholvin
>now, as straightforward a setup as there could be:
>
>private LAN 1 --- PIX 1 ----- internet ----- PIX 2 ----- private LAN 2
>
>negotiations. "show isakmp sa" returns 0 associations on both sides.
OK, I worked around the weird debug problem I had (thanks for the tips!) and
now I have the two pixes connected through isakmp phase II. But they still
won't pass traffic.
Here's is my theory. One of the pixes handles incoming VPN client connections
in addition to the "dedicated" connection to the other pix. Looking at the output
from "show ipsec sa" on that dual-purpose pix, I see something funny right at the
top:
interface: outside
Crypto map tag: CRYPTO_MAP, local addr. ee.ee.ee.ee
local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0)
current_peer: cc.cc.cc.cc:500
dynamic allocated peer ip: 0.0.0.0
(ee.ee.ee.ee and cc.cc.cc.cc are the public IPs of the pixes)
That dynamically allocated peer doesn't make sense to me. The other pix
doesn't have that line in the output. I'm guessing I have somehow
butchered the config of the crypto map and it's confusing this peer with the
VPN clients. The config of this pix is below, hopefully someone here can spot
the problem.
Summary:
* one pix is in Evanston (public=ee.ee.ee.ee), one in Chicago (cc.cc.cc.cc)
* the pix in Evanston also handles incoming VPN client connections
* the Evanston private lans are 10.1.0.0/16 and 192.168.0.0/24; and Chicago's is 10.2.0.0/16
Thanks in advance if anyone can spot the problem here.
PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ** encrypted
passwd ** encrypted
hostname pix-evn
domain-name **
clock timezone CST -6
clock summer-time CDT recurring
fixup protocol dns maximum-length 700
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
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
name ee.ee.ee.ee vpn-evn
object-group icmp-type icmp_traffic
icmp-object echo-reply
icmp-object source-quench
icmp-object unreachable
icmp-object time-exceeded
access-list PERMIT_IN permit icmp any any object-group icmp_traffic
access-list PERMIT_IN permit tcp any host ee.ee.ee.ee eq ssh
access-list PERMIT_IN permit tcp any host ee.ee.ee.ee eq www
access-list PERMIT_IN permit tcp any host ee.ee.ee.ee eq https
access-list PERMIT_IN permit udp any host ee.ee.ee.ee eq isakmp
access-list PERMIT_IN permit ah any host ee.ee.ee.ee
access-list PERMIT_IN permit esp any host ee.ee.ee.ee
access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.1.250.0 255.255.255.0
access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list CHICAGO permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
no pager
logging on
logging trap notifications
logging host inside 192.168.0.200
no logging message 106023
no logging message 305005
no logging message 304001
icmp permit any outside
icmp permit any inside
mtu outside 1500
mtu inside 1500
ip address outside ee.ee.ee.ee 255.255.255.248
ip address inside 10.1.1.1 255.0.0.0
ip audit info action alarm
ip audit attack action alarm
ip local pool REMOTE 10.1.250.1-10.1.250.254
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list NONAT
nat (inside) 1 192.168.0.0 255.255.255.0 0 0
nat (inside) 1 10.1.0.0 255.255.0.0 0 0
static (inside,outside) tcp interface ssh 192.168.0.200 ssh netmask 255.255.255.255 0 0
static (inside,outside) tcp interface www 192.168.0.200 www netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https 192.168.0.200 https netmask 255.255.255.255 0 0
static (inside,outside) udp interface syslog 192.168.0.200 syslog netmask 255.255.255.255 0 0
access-group PERMIT_IN in interface outside
route outside 0.0.0.0 0.0.0.0 ee.ee.ee.xx 1
route inside 192.168.0.0 255.255.255.0 10.1.1.254 1
timeout xlate 0:05: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 192.168.0.200 source inside
http server enable
http 192.168.0.0 255.255.255.0 inside
snmp-server host inside 192.168.0.200
snmp-server location headquarters
snmp-server contact scholvin
snmp-server community BASE2
snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set REMOTEACCESS esp-3des esp-sha-hmac
crypto ipsec transform-set LINK_TRANSFORM esp-des
crypto dynamic-map DYN_MAP 10 set transform-set REMOTEACCESS
crypto map CRYPTO_MAP 5 ipsec-isakmp
crypto map CRYPTO_MAP 5 match address CHICAGO
crypto map CRYPTO_MAP 5 set peer cc.cc.cc.cc
crypto map CRYPTO_MAP 5 set transform-set LINK_TRANSFORM
crypto map CRYPTO_MAP 99 ipsec-isakmp dynamic DYN_MAP
crypto map CRYPTO_MAP client configuration address initiate
crypto map CRYPTO_MAP client configuration address respond
crypto map CRYPTO_MAP interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0 no-xauth
isakmp key ******** address cc.cc.cc.cc netmask 255.255.255.255 no-xauth no-config-mode
isakmp client configuration address-pool local REMOTE outside
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption 3des
isakmp policy 5 hash sha
isakmp policy 5 group 2
isakmp policy 5 lifetime 86400
vpngroup VPN address-pool REMOTE
vpngroup VPN dns-server 192.168.0.200
vpngroup VPN default-domain **
vpngroup VPN split-tunnel NONAT
vpngroup VPN idle-time 1800
telnet timeout 5
ssh 192.168.0.0 255.255.255.0 inside
ssh 10.1.2.0 255.255.255.0 inside
ssh timeout 60
console timeout 0
dhcpd dns 192.168.0.200
dhcpd lease 36000
dhcpd ping_timeout 750
dhcpd domain **
dhcpd auto_config outside
terminal width 80
Cryptochecksum:12eec7df7bc1300fec770a683fb9b1d8
Walter Roberson
John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
> Crypto map tag: CRYPTO_MAP, local addr. ee.ee.ee.ee
> local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
> remote ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0)
> current_peer: cc.cc.cc.cc:500
> dynamic allocated peer ip: 0.0.0.0
>(ee.ee.ee.ee and cc.cc.cc.cc are the public IPs of the pixes)
>That dynamically allocated peer doesn't make sense to me.
That line is fine, I see that all the time.
>PIX Version 6.3(3)
Should upgrade to 6.3(4) for security fixes, 6.3(5) for bug fixes.
>ip address inside 10.1.1.1 255.0.0.0
>ip local pool REMOTE 10.1.250.1-10.1.250.254
Never have your vpn address pool as a subset of your inside addresses.
This -will- lead to VPN problems in PIX 6.x.
>access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.1.250.0 255.255.255.0
>access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
>access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
>access-list CHICAGO permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
Why are you using 10.1/16 as your source on those when your
inside address range is 10/8 and 192.168.0/24 ?
>global (outside) 1 interface
>nat (inside) 0 access-list NONAT
>nat (inside) 1 192.168.0.0 255.255.255.0 0 0
>nat (inside) 1 10.1.0.0 255.255.0.0 0 0
I notice you do not have any translation specified for the rest
of 10/8 ?
>isakmp client configuration address-pool local REMOTE outside
>vpngroup VPN address-pool REMOTE
Cisco recommends that you do not use both of those commands
together unless you have multiple tunnels.
>vpngroup VPN split-tunnel NONAT
It is usually a problem to use the same ACL for two purposes;
you are using NONAT for nat 0 access-list and for split-tunnel.
The PIX likes to modify ACLs internally; it -will- do so for
ACLs applied as access-groups, and several bug reports together
suggest that it does so even for some other ACLs for no logical
reason that I could come up with.
John Scholvin
In article <0RfGf.583241$ki.280779@pd7tw2no>,
Walter Roberson <robe...@hushmail.com> wrote:
>In article <dsbvje$dfm$1...@chessie.cirr.com>,
>John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
>>PIX Version 6.3(3)
>
>Should upgrade to 6.3(4) for security fixes, 6.3(5) for bug fixes.
done.
>>ip address inside 10.1.1.1 255.0.0.0
>>ip local pool REMOTE 10.1.250.1-10.1.250.254
>
>Never have your vpn address pool as a subset of your inside addresses.
>This -will- lead to VPN problems in PIX 6.x.
GAK! Major typo. Should be ip address inside 10.1.1.1 255.255.255.0. This
has been wrong for a long, long time. Now fixed; didn't make too much of a
difference that I can see.
>>access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.1.250.0
255.255.255.0
>>access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
>>access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
>>access-list CHICAGO permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
>
>Why are you using 10.1/16 as your source on those when your
>inside address range is 10/8 and 192.168.0/24 ?
Well, see above re: typo of netmask.
>>global (outside) 1 interface
>>nat (inside) 0 access-list NONAT
>>nat (inside) 1 192.168.0.0 255.255.255.0 0 0
>>nat (inside) 1 10.1.0.0 255.255.0.0 0 0
>
>I notice you do not have any translation specified for the rest
>of 10/8 ?
Ditto...
>>isakmp client configuration address-pool local REMOTE outside
>>vpngroup VPN address-pool REMOTE
>
>Cisco recommends that you do not use both of those commands
>together unless you have multiple tunnels.
I took the isakmp statement out.
>It is usually a problem to use the same ACL for two purposes;
I redid the access lists. I'll post the whole config (plus the show crypto
output below for context), but here's what I did, and why.
access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.1.250.0 255.255.255.0
access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.2.0.0 255.255.255.0
nat (inside) 0 NONAT
The idea here is that I have 2 lans (10.1/16 and 192.168.0/24) behind the
PIX (Evanston), the remote private lan (Chicago) is 10.2/16, and the VPN
client users who attach to this PIX have the address pool 10.1.250.1 -
10.1.250.254.
My reasoning is that I don't want NAT between my private networks, and I
don't want NAT between Evanston and the VPN clients. Correct? (I'm not
considering NAT between the VPN clients and Chicago right now, though I
suppose I will.)
access-list CHICAGO permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list CHICAGO permit ip 192.168.0.0 255.255.255.0 10.2.0.0 255.255.0.0
crypto map CRYPTO_MAP 5 match address CHICAGO
This is the ACLs that defines the "interesting" Evanston to Chicago traffic
for the tunnel.
access-list VPNSPLIT permit ip 192.168.0.0 255.255.255.0 10.1.250.0 255.255.255.0
access-list VPNSPLIT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
access-list VPNSPLIT permit ip 10.2.0.0 255.255.0.0 10.1.250.0 255.255.255.0
vpngroup VPN split-tunnel VPNSPLIT
And this ACL is for the VPN clients' split-tunnel.
Am I completely missing the boat on these???
Here's where I am now: isakmp is established, but I still can't get traffic
between Evanston and Chicago. If I try to traceroute from Evanston to
Chicago, I see a bunch of intermediate hops past my ISP's router, which I am
guessing is wrong. If the tunnel is correct, shouldn't traceroute show it
going from my pix straight to the other pix?
Thanks again for all assistance...full PIX config and crypto output below.
PIX Version 6.3(5)
interface ethernet0 auto
interface ethernet1 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ** encrypted
passwd ** encrypted
hostname pix-evn
domain-name **
clock timezone CST -6
clock summer-time CDT recurring
fixup protocol dns maximum-length 700
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
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol tftp 69
names
name 192.168.0.200 utility
name ee.ee.ee.ee router01
name cc.cc.cc.cc vpn-chi
name ee.ee.ee.ee vpn-evn
name 10.1.1.254 router02
name 10.1.1.1 pix-evn
object-group icmp-type icmp_traffic
icmp-object echo-reply
icmp-object source-quench
icmp-object unreachable
icmp-object time-exceeded
access-list PERMIT_IN permit icmp any any object-group icmp_traffic
access-list PERMIT_IN permit tcp any host vpn-evn eq ssh
access-list PERMIT_IN permit tcp any host vpn-evn eq www
access-list PERMIT_IN permit tcp any host vpn-evn eq https
access-list PERMIT_IN permit udp host router01 host vpn-evn eq syslog
access-list PERMIT_IN permit udp host router01 any eq snmp
access-list PERMIT_IN permit udp any host vpn-evn eq isakmp
access-list PERMIT_IN permit ah any host vpn-evn
access-list PERMIT_IN permit esp any host vpn-evn
access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.1.250.0 255.255.255.0
access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
access-list NONAT permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list NONAT permit ip 192.168.0.0 255.255.255.0 10.2.0.0 255.255.255.0
access-list CHICAGO permit ip 10.1.0.0 255.255.0.0 10.2.0.0 255.255.0.0
access-list CHICAGO permit ip 192.168.0.0 255.255.255.0 10.2.0.0 255.255.0.0
access-list VPNSPLIT permit ip 192.168.0.0 255.255.255.0 10.1.250.0 255.255.255.0
access-list VPNSPLIT permit ip 10.1.0.0 255.255.0.0 10.1.250.0 255.255.255.0
access-list VPNSPLIT permit ip 10.2.0.0 255.255.0.0 10.1.250.0 255.255.255.0
no pager
logging on
logging trap notifications
logging host inside utility
no logging message 106023
no logging message 305005
no logging message 304001
icmp permit any outside
icmp permit any inside
mtu outside 1500
mtu inside 1500
ip address outside vpn-evn 255.255.255.248
ip address inside pix-evn 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool REMOTE 10.1.250.1-10.1.250.254
pdm logging informational 100
pdm history enable
arp timeout 14400
global (outside) 1 interface
nat (inside) 0 access-list NONAT
nat (inside) 1 192.168.0.0 255.255.255.0 0 0
nat (inside) 1 10.1.0.0 255.255.0.0 0 0
static (inside,outside) tcp interface ssh utility ssh netmask 255.255.255.255 0 0
static (inside,outside) tcp interface www utility www netmask 255.255.255.255 0 0
static (inside,outside) tcp interface https utility https netmask 255.255.255.255 0 0
static (inside,outside) udp interface syslog utility syslog netmask 255.255.255.255 0 0
access-group PERMIT_IN in interface outside
route outside 0.0.0.0 0.0.0.0 router01 1
route inside 10.1.0.0 255.255.0.0 router02 1
route inside 192.168.0.0 255.255.255.0 router02 1
timeout xlate 0:05: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 sip-disconnect 0:02:00 sip-invite 0:03: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
ntp server utility source inside
http server enable
http 192.168.0.0 255.255.255.0 inside
snmp-server host inside utility
snmp-server location headquarters
snmp-server contact scholvin
snmp-server community BASE2
snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
crypto ipsec transform-set REMOTEACCESS esp-3des esp-sha-hmac
crypto ipsec transform-set LINK_TRANSFORM esp-des
crypto dynamic-map DYN_MAP 10 set transform-set REMOTEACCESS
crypto map CRYPTO_MAP 5 ipsec-isakmp
crypto map CRYPTO_MAP 5 match address CHICAGO
crypto map CRYPTO_MAP 5 set peer vpn-chi
crypto map CRYPTO_MAP 5 set transform-set LINK_TRANSFORM
crypto map CRYPTO_MAP 99 ipsec-isakmp dynamic DYN_MAP
crypto map CRYPTO_MAP client configuration address initiate
crypto map CRYPTO_MAP client configuration address respond
crypto map CRYPTO_MAP interface outside
isakmp enable outside
isakmp key ******** address 0.0.0.0 netmask 0.0.0.0 no-xauth
isakmp key ******** address vpn-chi netmask 255.255.255.255 no-xauth no-config-mode
isakmp identity address
isakmp policy 5 authentication pre-share
isakmp policy 5 encryption 3des
isakmp policy 5 hash sha
isakmp policy 5 group 2
isakmp policy 5 lifetime 86400
vpngroup VPN address-pool REMOTE
vpngroup VPN dns-server utility
vpngroup VPN default-domain **
vpngroup VPN split-tunnel VPNSPLIT
vpngroup VPN idle-time 1800
telnet timeout 5
ssh 192.168.0.0 255.255.255.0 inside
ssh 10.1.0.0 255.255.0.0 inside
ssh timeout 60
console timeout 0
dhcpd dns utility
dhcpd lease 36000
dhcpd ping_timeout 750
dhcpd domain **
dhcpd auto_config outside
terminal width 80
Cryptochecksum:b3e43898f90b3c05db21b856a1f836dc
pix-evn# show isakmp sa
Total : 1
Embryonic : 0
dst src state pending created
vpn-chi vpn-evn QM_IDLE 0 1
pix-evn# show ipsec sa
interface: outside
Crypto map tag: CRYPTO_MAP, local addr. vpn-evn
local ident (addr/mask/prot/port): (10.1.0.0/255.255.0.0/0/0)
remote ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0)
current_peer: vpn-chi:500
dynamic allocated peer ip: 0.0.0.0
PERMIT, flags={origin_is_acl,}
#pkts encaps: 8, #pkts encrypt: 8, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0
local crypto endpt.: vpn-evn, remote crypto endpt.: vpn-chi
path mtu 1500, ipsec overhead 44, media mtu 1500
current outbound spi: e37f42c8
inbound esp sas:
spi: 0xdbeb684c(3689637964)
transform: esp-des ,
in use settings ={Tunnel, }
slot: 0, conn id: 2, crypto map: CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4608000/28240)
IV size: 8 bytes
replay detection support: N
inbound ah sas:
inbound pcp sas:
outbound esp sas:
spi: 0xe37f42c8(3816768200)
transform: esp-des ,
in use settings ={Tunnel, }
slot: 0, conn id: 1, crypto map: CRYPTO_MAP
sa timing: remaining key lifetime (k/sec): (4607999/28240)
IV size: 8 bytes
replay detection support: N
outbound ah sas:
outbound pcp sas:
local ident (addr/mask/prot/port): (192.168.0.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (10.2.0.0/255.255.0.0/0/0)
current_peer: vpn-chi:0
PERMIT, flags={origin_is_acl,}
#pkts encaps: 0, #pkts encrypt: 0, #pkts digest 0
#pkts decaps: 0, #pkts decrypt: 0, #pkts verify 0
#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.: vpn-evn, remote crypto endpt.: vpn-chi
path mtu 1500, ipsec overhead 0, media mtu 1500
current outbound spi: 0
inbound esp sas:
inbound ah sas:
inbound pcp sas:
outbound esp sas:
outbound ah sas:
outbound pcp sas:
Walter Roberson
John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
>In article <0RfGf.583241$ki.280779@pd7tw2no>,
>Walter Roberson <robe...@hushmail.com> wrote:
>>In article <dsbvje$dfm$1...@chessie.cirr.com>,
>>John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
>>>ip address inside 10.1.1.1 255.0.0.0
>>>ip local pool REMOTE 10.1.250.1-10.1.250.254
>>Never have your vpn address pool as a subset of your inside addresses.
>GAK! Major typo. Should be ip address inside 10.1.1.1 255.255.255.0.
But that's not what you put into your configuration. Your configuration
has ip address inside 10.1.1.1 255.255.0.0 which still has all
the overlap problems.
John Scholvin
?
No, it's there in the previous article as:
>> ip address inside pix-evn 255.255.255.0
(pix-evn = name for 10.1.1.1).
Maybe I wasn't clear, and for that I'm sorry. The pix inside interface is on
the 10.1.1/24 network, and there is also a router on that network which
routes to 10.1.2/24, 10.1.3/24, and 192.168.0/24. And all hosts on all of
those networks need to be reachable by VPN clients and the other pix. Hence,
I need 10.1/16 for the NONAT and CHICAGO acl's.
Am I hopelessly confused?
Walter Roberson
John Scholvin <jo...@scholvin.com.REMOVETHIS> wrote:
>In article <vaqGf.465567$2k.418683@pd7tw1no>,
>Walter Roberson <robe...@hushmail.com> wrote:
>>But that's not what you put into your configuration. Your configuration
>>has ip address inside 10.1.1.1 255.255.0.0 which still has all
>>the overlap problems.
>No, it's there in the previous article as:
>>> ip address inside pix-evn 255.255.255.0
Sorry, I read the wrong line.
But you do have
route inside 10.1.0.0 255.255.0.0 router02 1
and that's going to interfere with reaching 10.1.250/24 outside.
I would suggest that you don't try to use 10.1/16 anywhere in
your configuration. If you want to cover 10.1.1/24, 10.1.2/24,
and 10.1.3/24, then create an object-group that covers those and
use that object group where appropriate.
John Scholvin
Walter Roberson <robe...@hushmail.com> wrote:
>I would suggest that you don't try to use 10.1/16 anywhere in
>your configuration. If you want to cover 10.1.1/24, 10.1.2/24,
>and 10.1.3/24, then create an object-group that covers those and
>use that object group where appropriate.
This worked; thanks!
It would seem that what I've uncovered here is a bad network numbering
scheme. Maintaining these object groups inside the pix forever as we add new
subnets seems like a drag; it would be a lot easier if I could just say
"tunnel everything on 10.1/16 to 10.2/16" and be done with it.
So, what would be conventional here? I assume putting the pix's inside
interface on some totally different network would be the way to go, like
172.16.1/24 or something. Is there any sort of convention for this kind of
thing?
Thanks for all your extremely valuable help!
john