Link to home
Start Free TrialLog in
Avatar of Tim Holman
Tim HolmanFlag for United Kingdom of Great Britain and Northern Ireland

asked on

VPN Concentrator behind a PIX

Here goes...

At the moment, I have setup several site-site and client-site VPNs with the following simple setup:

Internet
|
PIX
|
Internal network

Everything is fine, hunky-dory.  Now, my client wants to do this:

Internet
|
PIX-------------VPN Concentrator (private address)
|                     |
Internal network

So I thought fine, should be OK, I'll just redirect all the VPN traffic from the PIX's outside interface to the new VPN conc on the DMZ using:

static (dmz1,outside) udp 111.111.111.238  500 10.1.1.3 500 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.238 4500 10.1.1.3 4500 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.238 10000 10.1.1.3 10000 netmask 255.255.255.255 0 0

(where 111.111.111.238 is the OUTSIDE interface address of the PIX)

..and removing the crypto map from the PIX:

no crypto map fhlon interface outside

..and removing ISAKMP from the outside PIX interface:

no isakmp enable outside

sysopt connection permit-ipsec is enabled, which permits IPSEC related traffic (hopefully udp ports 500, 4500 and 10000), but I've tried it with any any access lists just to make sure, and still no difference to the problem below.

I've also reloaded the PIX to clear out the keys (clear cry isa sa didn't seem to be enough !).

The problem I'm having is that the VPN Concentrator and the remote VPN sites (mostly Cisco 837s) establish VPN tunnels, but NO traffic is going down them.  The internal routing has been changed to point VPN-bound traffic to the VPN Concentrator and NOT the PIX.
NAT-T is being negotiated OK from what I see from the logs.

I'm wondering if there's anything else I need to do to this PIX in order to ensure VPN traffic is redirected to the VPN Concentrator ?    I'm thinking somehow that the remote VPN devices are still 'sticking' to the PIX.  I've tried rebooting some of the remote devices, but things don't appear to work still.
As a last ditch attempt, I will try giving the VPN Conc an Internet IP address and putting it directly on the Internet, but this is going to be a few weeks off whilst we sort out IP addressing (none left, basically...)

Full config below...


: Saved
:
PIX Version 6.3(3)
interface ethernet0 auto
interface ethernet1 100full
interface ethernet2 auto
nameif ethernet0 outside security0
nameif ethernet1 inside security100
nameif ethernet2 dmz1 security50
enable password something encrypted
passwd something encrypted
hostname something
domain-name something
fixup protocol dns maximum-length 512
fixup protocol ftp 21
fixup protocol h323 h225 1720
fixup protocol h323 ras 1718-1719
no fixup protocol http 80
fixup protocol ils 389
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
name 10.1.1.0 DMZ-NET
name 10.1.1.2 MAILSWEEPER
name 10.1.130.27 EXCHANGE-SVR
name 10.1.130.12 DATASVR01_CORP
name 10.1.130.13 PROXY-SVR
name 192.168.253.0 CISCOCLIENTS
name 10.1.130.14 FESVR01
name 172.30.6.0 GV_LAN
name 10.1.130.15 EXTRANET-SVR
access-list inbound permit icmp any any echo-reply
access-list inbound permit tcp any host 111.111.111.226 eq smtp
access-list inbound permit tcp any host 111.111.111.227 eq https
access-list inbound permit tcp any host 111.111.111.228 eq imap4
access-list inbound permit tcp any host 111.111.111.228 eq smtp
access-list inbound permit tcp any host 111.111.111.229 eq https
access-list inbound permit udp any host 111.111.111.229 eq isakmp
access-list inbound permit udp any host 111.111.111.229 eq 4500
access-list inbound permit udp any host 111.111.111.229 eq 10000
access-list nonat permit ip 10.1.128.0 255.255.248.0 CISCOCLIENTS 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.20.1.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.13.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.9.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.12.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.2.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.3.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.4.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.5.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.8.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.11.0 255.255.255.240
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.16.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.14.0 255.255.255.248
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.17.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.18.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.19.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.98.0 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.7.0 255.255.255.240
access-list nonat permit ip GV_LAN 255.255.255.0 CISCOCLIENTS 255.255.255.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.16.0.0 255.255.248.0
access-list nonat permit ip 10.1.128.0 255.255.248.0 172.30.21.0 255.255.255.0
access-list outbound permit udp any any eq domain
access-list outbound deny icmp any 10.0.0.0 255.0.0.0
access-list outbound permit icmp any any echo
access-list outbound permit tcp host DATASVR01_CORP host MAILSWEEPER eq 799
access-list outbound permit ip host EXCHANGE-SVR host MAILSWEEPER
access-list outbound permit tcp host EXCHANGE-SVR any
access-list outbound permit ip 10.1.128.0 255.255.248.0 172.16.0.0 255.255.0.0
access-list outbound permit ip 10.1.128.0 255.255.248.0 172.20.1.0 255.255.255.0
access-list outbound permit ip 10.1.128.0 255.255.248.0 172.30.0.0 255.255.0.0
access-list outbound permit tcp host PROXY-SVR any eq www
access-list outbound permit tcp host PROXY-SVR any eq https
access-list outbound permit tcp 10.1.128.0 255.255.248.0 any eq ftp
access-list outbound permit tcp 10.1.128.0 255.255.248.0 any eq ftp-data
access-list outbound permit tcp any host 217.64.228.113 eq www
access-list outbound permit tcp host 10.1.130.25 host 193.109.81.33 eq 3101
access-list outbound permit tcp host PROXY-SVR 65.247.142.0 255.255.255.128 eq 7520
access-list outbound permit tcp host DATASVR01_CORP host 111.111.111.225 eq telnet
access-list outbound permit tcp host DATASVR01_CORP host 111.111.111.225 eq 162
access-list outbound permit tcp host DATASVR01_CORP host 111.111.111.225 eq 163
access-list outbound permit tcp host CISCOCLIENTS host 10.1.130.5 eq https
access-list outbound permit tcp GV_LAN 255.255.255.0 any eq www
access-list outbound permit tcp GV_LAN 255.255.255.0 any eq https
access-list outbound permit ip GV_LAN 255.255.255.0 CISCOCLIENTS 255.255.255.0
access-list outbound permit icmp GV_LAN 255.255.255.0 CISCOCLIENTS 255.255.255.0
access-list outbound permit udp any host 65.240.90.25 eq isakmp
access-list outbound permit udp any host 65.240.90.25 eq 10000
access-list outbound permit tcp host 10.1.130.70 any eq www
access-list outbound permit tcp host 10.1.130.70 any eq https
access-list dmz-in deny icmp any any echo
access-list dmz-in permit ip host MAILSWEEPER any
* access lists for all the VPNs follow, but I've removed them for security reasons.  The networks all match up 100% anyway -

* this is not the problem !
pager lines 24
logging console debugging
mtu outside 1500
mtu inside 1500
mtu dmz1 1500
ip address outside 111.111.111.238 255.255.255.240
ip address inside 10.1.128.1 255.255.255.0
ip address dmz1 10.1.1.1 255.255.255.0
ip verify reverse-path interface outside
ip audit info action alarm
ip audit attack action alarm
ip local pool ciscoclients 192.168.253.1-192.168.253.50
no failover
failover timeout 0:00:00
failover poll 15
no failover ip address outside
no failover ip address inside
no failover ip address dmz1
pdm location 10.1.128.0 255.255.248.0 inside
pdm location 172.20.1.0 255.255.255.0 outside
pdm location GV_LAN 255.255.255.0 outside
pdm location 172.30.9.0 255.255.255.248 outside
pdm location 172.30.12.0 255.255.255.248 outside
pdm location 172.30.13.0 255.255.255.248 outside
pdm location CISCOCLIENTS 255.255.255.0 outside
pdm location FESVR01 255.255.255.255 inside
pdm location EXCHANGE-SVR 255.255.255.255 inside
pdm location CISCOCLIENTS 255.255.255.0 inside
pdm location MAILSWEEPER 255.255.255.255 dmz1
pdm history enable
arp timeout 14400
global (outside) 1 interface
global (outside) 5 111.111.111.228
nat (inside) 0 access-list nonat
nat (inside) 5 EXTRANET-SVR 255.255.255.255 0 0
nat (inside) 5 EXCHANGE-SVR 255.255.255.255 0 0
nat (inside) 1 GV_LAN 255.255.255.0 0 0
nat (inside) 1 10.1.128.0 255.255.248.0 0 0
nat (dmz1) 1 MAILSWEEPER 255.255.255.255 0 0
static (inside,outside) tcp 111.111.111.227 https FESVR01 https netmask 255.255.255.255 0 0
static (inside,outside) tcp 111.111.111.228 imap4 EXCHANGE-SVR imap4 netmask 255.255.255.255 0 0
static (inside,outside) tcp 111.111.111.228 smtp EXCHANGE-SVR smtp netmask 255.255.255.255 0 0
static (inside,outside) tcp 111.111.111.229 https EXTRANET-SVR https netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.229 isakmp 10.1.1.3 isakmp netmask 255.255.255.255 0 0
static (dmz1,outside) tcp 111.111.111.229 5000 10.1.1.3 https netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.229 4500 10.1.1.3 4500 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.229 10000 10.1.1.3 10000 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.238  500 10.1.1.3 500 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.238 4500 10.1.1.3 4500 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.238 10000 10.1.1.3 10000 netmask 255.255.255.255 0 0
static (inside,dmz1) 10.1.130.0 10.1.130.0 netmask 255.255.255.0 0 0
static (dmz1,outside) 111.111.111.226 MAILSWEEPER netmask 255.255.255.255 0 0
access-group inbound in interface outside
access-group outbound in interface inside
access-group dmz-in in interface dmz1
route outside 0.0.0.0 0.0.0.0 111.111.111.225 1
route inside 10.1.129.0 255.255.255.0 10.1.128.254 1
route inside 10.1.130.0 255.255.255.0 10.1.128.254 1
route inside 10.1.131.0 255.255.255.0 10.1.128.254 1
route inside 10.1.132.0 255.255.255.0 10.1.128.254 1
route inside 10.1.133.0 255.255.255.0 10.1.128.254 1
route inside 10.1.134.0 255.255.255.0 10.1.128.254 1
route inside 10.1.135.0 255.255.255.0 10.1.128.254 1
route inside GV_LAN 255.255.255.0 10.1.128.254 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 RADIUS protocol radius
aaa-server LOCAL protocol local
http server enable
http 10.1.128.0 255.255.248.0 inside
http CISCOCLIENTS 255.255.255.0 inside
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
crypto ipsec transform-set ESP-3DES-MD5 esp-3des esp-md5-hmac
crypto dynamic-map clientvpn 90 set transform-set ESP-3DES-MD5
* crypto maps for all the VPNs follow, but I've removed them for security reasons.  The proposals all match up 100% anyway -

* this is not the problem !
crypto map fhlon client configuration address respond
crypto map fhlon interface outside
isakmp enable outside
* Lots of isakmp keys & IP address follow, but I've removed them for security reasons
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption 3des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
isakmp policy 11 authentication pre-share
isakmp policy 11 encryption des
isakmp policy 11 hash md5
isakmp policy 11 group 2
isakmp policy 11 lifetime 86400
vpngroup cisco address-pool ciscoclients
vpngroup cisco dns-server DATASVR01_CORP
vpngroup cisco wins-server DATASVR01_CORP
vpngroup cisco idle-time 3600
vpngroup cisco password ********
telnet 10.1.128.0 255.255.248.0 inside
telnet CISCOCLIENTS 255.255.255.0 inside
telnet timeout 5
ssh timeout 5
management-access inside
console timeout 0
terminal width 80
Cryptochecksum:b2ad84045d3c34de883f1ad7ecde97d4
: end
Avatar of Pete Long
Pete Long
Flag of United Kingdom of Great Britain and Northern Ireland image

Morning Tim, unsure? if your tunnels are coming up but nothing is going down them Id be more inclined to this it was a routing problem? do you have any lecacy static routes pointing traffic at the pix?
I believe that you have a routing issue. Local systems default gateway to PIX?
What IP subnet do clients get? Same as they did on the PIX? 192.168.x.x? A different subnet than on the LAN?
Have you permitted TCP port 500 in your acl? I see UDP 500.....

If VPN users get an IP address that is different from the local LAN, It would definately present a routing issue that is not easy to fix without another router or L3 switch on the inside net.

My suggestion, and the way I set up VPN concentrators is just a little different:

 Internet
 |        |
PIX -- VPN3000
 |
Inside

Where the VPN concentrator's INSIDE interface terminates on the DMZ of the PIX. This way, we can see the actual traffic between VPN users and the local LAN, and control that with the PIX access-lists. This does several things.
Removes any inbound PIX issues, diverting to another interface
Makes routing much easier. The PIX can route between interfaces, and participate in OSPF with the VPN3000. Not so if if the VPN3000 terminates on the inside LAN and the PIX is the default gateway for everyone.
Avatar of hawgpig
hawgpig

I agree with pete...check your route inside statements and make sure they are copacetic.
Sounds like a routing problem to me also...
Good Luck
>The internal routing has been changed to point VPN-bound traffic to the VPN Concentrator and NOT the PIX.

DOH! Sorry, Tim, for not paying enough attention to detail in your problem description.

These are LAN-LAN tunnels to remote sites...
Definately open TCP port 500 on the PIX, then.


Avatar of Tim Holman

ASKER

Thanks all...  I'm pretty sure there's a routing issue too, but I have full access to the default gateway on the internal network (a Cisco 3550 switch with ip routing enabled), and have fully populated this with routes to the remote LANs to go specifically via the VPN 3000.

I would prefer if the VPN conc was laid out as lrmoore has described - public interface on the Internet, private to the DMZ, but client insists he wants to keep the external IP address of the PIX as the 'VPN address', so that we don't have to reconfigure the twenty odd VPN nodes out there to point to the new address of the VPN 3000.

Out of interest, what ports does sysopt connection permit-ipsec open up ?
I'm assuming it opens up TCP/UDP 500, UDP 4500 and UDP 10000 instead of having to apply an access-list with these ports in instead (which I've also tried!) ?

static (dmz1,outside) udp 111.111.111.229 isakmp 10.1.1.3 isakmp netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.229 4500 10.1.1.3 4500 netmask 255.255.255.255 0 0
static (dmz1,outside) udp 111.111.111.229 10000 10.1.1.3 10000 netmask 255.255.255.255 0 0
static (dmz1,outside) tcp 111.111.111.238  500 10.1.1.3 500 netmask 255.255.255.255 0 0
static (dmz1,outside) tcp 111.111.111.238 4500 10.1.1.3 4500 netmask 255.255.255.255 0 0
static (dmz1,outside) tcp 111.111.111.238 10000 10.1.1.3 10000 netmask 255.255.255.255 0

Bit of a pain really - I'm pretty sure I could debug this and get it working within an hour or so, but as it's a live VPN setup, I'm not allowed to move things over for any longer than about 5 mins as they're not particularly downtime-centric....  ;)

Points agreed about the VPN client addressing - I will renumber to an alternate subnet within the internal range.

Also, if the PIX is still somehow engaged in underhand VPN activity after removing 'isakmp enable outside' and the 'crypto map' from the outside interface (and reloading), is there a more specific way to ensure that it won't try it's luck and participate in any VPN transaction ?  ie completely remove all keys ?  I'm assuming stuff is stored in memory otherwise I wouldn't have to keep reloading it to get the VPNs up...
>what ports does sysopt connection permit-ipsec open up
None specifically to an internal host. This is for internal processing only, not for passthrough to another VPN host.

I see...  so I need access lists for TCP/UDP 500, UDP 500 and UDP 10000 in order to support this ?
Are there any ports I've missed from this ?
I take it ESP cannot be NATted ?
Is ICMP required ?  Can that be NATted ?

...just thinking aloud again, but it's my question so I can waffle as much as I like !
ASKER CERTIFIED SOLUTION
Avatar of Les Moore
Les Moore
Flag of United States of America image

Link to home
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial
Thanks for looking... !

111.111.111.238 is the outside PIX address.  We want this to be the NATted address for the VPN concentrator as well, so we can't use 1-to-1 NAT (as the same address is in use by the PIX).
There's no further dual-purposing.  The original administrator decided to use different public IP addresses for the purposes of port redirection for SMTP, HTTPS etc, so he's used up the allocation...  doh.

I was thinking ESP protocol # 50, AH protocol # 51, that sort of thing, but I think these days that most installations encapsulate this anyway, so probably the wrong track !

To summarise, is it just TCP/UDP 500, UDP 4500 and UDP 10000 which I need to port-redirect to get ALL VPN functions moved from the PIX external address to the VPN 3000 on the DMZ ?

Port-forward:

tcp 500 <- esp
udp 50 <- ISAKMP
udp 4500 <- VPN 4.x clients
udp 10000 <- clients
tcp 10000 <- clients if you have the 3005 enabled for TCP

That "should" do it.
Definately suggest 1-1 static.
Definately.
So what if you have to change your clients. Just send them a new .pcf text file with instructions to save it in their \Profiles directory
Then VPN clients work without any problems with the above config - redirection doesn't seem to upset things.
It's the site-to-site VPNs that aren't working.  Well, they sort of work in that sometimes phase 1 completes, and sometimes phase 1 and phase 2 complete, but nothing seems to stay up.  I even got into a situation where I could SEND traffic from behind the VPN 3005 to the remote network, but nothing cames back (0 bytes received..).  
All points to a routing problem, but I can't find a routing problem... aaarghghghgh !!!
Oh well...  I've got some out-of-hours time scheduled to work through this problem, but if I can't fix it, then they're going to get a different IP address and connect directly to the Internet....  ;)

FYI - when I do:

static (dmz1,outside) udp 111.111.111.229 500 10.1.1.3 500 netmask 255.255.255.255 0 0

it ends up like this in the config:

static (dmz1,outside) udp 111.111.111.229 isakmp 10.1.1.3 isakmp netmask 255.255.255.255 0 0

...so Cisco match udp 500 to udp isakmp.


Maybe I have it backwards.....
TCP 50 = ESP
UDP 500 = ISAKMP

Try opening TCP 50
Are you still working on this? Any updates for us, Tim?
All gone a bit quiet...  still waiting for client to give me some scheduled downtime to play around with this...  ;)
No such luck for any scheduled downtime.  The client went behind my back to their account manager and to my manager to complain about the amount of downtime this caused them, even though it was agreed in the first place... sigh.
So, I'm off the project... !
I didn't see any reason why this wouldn't work, but it looks like this will be re-architected with a public IP address from a pool they never knew they had, but with someone else doing the work.
B*stards.
Hi.

I don't know if you still have the chance to make changes, but from what I see

  static (dmz1,outside) udp 111.111.111.229 500 10.1.1.3 500 netmask 255.255.255.255 0 0

only give you access to port udp 500.

you need to open protocol 50 (esp) and not so sure but you can do it protocol 51 (ah) like these

  static (dmz1,outside) 111.111.111.229 10.1.1.3 netmask 255.255.255.255 0 0

  access-list inbound permit udp any host 111.111.111.229 eq isakmp
  access-list inbound permit 50 any host 111.111.111.229
  access-list inbound permit 51 any host 111.111.111.229
  access-list dmz-in permit udp host 111.111.111.229 any eq isakmp
  access-list dmz-in permit 50 host 111.111.111.229 any eq
  access-list dmz-in permit 51 host 111.111.111.229 any eq