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
formatting link
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?
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.
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".
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...
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
(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
Should upgrade to 6.3(4) for security fixes, 6.3(5) for bug fixes.
Never have your vpn address pool as a subset of your inside addresses. This -will- lead to VPN problems in PIX 6.x.
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 ?
I notice you do not have any translation specified for the rest of 10/8 ?
Cisco recommends that you do not use both of those commands together unless you have multiple tunnels.
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.
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.
Well, see above re: typo of netmask.
Ditto...
I took the isakmp statement out.
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
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
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.
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.
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.
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?
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.