Solved

Quick PIX 515e VPN Question

Posted on 2004-10-08
20
1,763 Views
Last Modified: 2013-11-16
I'm currently trying to get our VPN setup using a PIX 515e and PPTP authentication (Windows XP logins).  The connection seems to establish just fine and I can get to any site but nothing WITHIN my network, nothing works ping, http, etc.  Any help would be appreciated.
0
Comment
Question by:rkekos
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 10
  • 9
20 Comments
 
LVL 79

Expert Comment

by:lrmoore
ID: 12258202
You'll have to post your config, but most important is
  ip address inside 192.168.x.1 255.255.255.0  <== make sure x does not equal 0 or 1
  ip local pool WORD <start ip> <end ip>
  access-list nat_0 permit ip <local subnet> <mask> <pool subnet> <mask>
  nat (inside) 0 access-list nat_o

 Then all of your vpdn config.

Assuming that your local pool is a different subnet than the inside LAN, on the client you have two choices:
1) check the box [x] Use Default Gateway on remote network
2) manually set a route every time you connect
   c:\>route add <lan subnet> mask <mask> <ip received by vpn client>

One workaround is to use maskable sub-groups (not masks) of the LAN for the VPN clients.
Example:
  Local LAN is 192.168.122.0 using addresses .1 - 127 mask 255.255.255.0
  VPN Pool is 192.168.122.193-.254  <no mask specifified>
Now the nat0 access list can make more sense, yet they still appear within the same "real" mask.
   access-list nat_0 permit ip 192.168.122.0 255.255.255.128 192.168.122.192 255.255.255.192
0
 

Author Comment

by:rkekos
ID: 12260704
Thanks for the help lrmoore ... here's some of my info:

ip address outside 208.42.237.126 255.255.255.248
ip address inside 69.24.64.1 255.255.240.0
...
...
vpdn group MyVPN accept dialin pptp
vpdn group MyVPN ppp authentication pap
vpdn group MyVPN ppp authentication chap
vpdn group MyVPN ppp authentication mschap
vpdn group MyVPN ppp encryption mppe auto required
vpdn group MyVPN client configuration address local VPN
vpdn group MyVPN client configuration dns 69.24.64.251
vpdn group MyVPN pptp echo 60
vpdn group MyVPN client authentication local
vpdn username UserVPN password ************
vpdn enable outside
vpdn enable inside
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12260919
I'll need to see more of the config. ..
0
Surfing Is Meant To Be Done Outdoors

Featuring its rugged IP67 compliant exterior and delivering broad, fast, and reliable Wi-Fi coverage, the AP322 is the ideal solution for the outdoors. Manage this AP with either a Firebox as a gateway controller, or with the Wi-Fi Cloud for an expanded set of management features

 

Author Comment

by:rkekos
ID: 12260977
Thanks ... like what?  Here's some more info:

nameif ethernet0 outside security0
nameif ethernet1 inside security100
access-list 101 permit tcp any any
access-list 101 permit udp any any
access-list 101 permit icmp any any
access-list 101 permit tcp 69.24.64.224 255.255.255.252 any
access-list 101 permit ip 69.24.64.224 255.255.255.252 any
access-list inside_outbound_nat0_acl permit ip any 69.24.64.224 255.255.255.252
access-list outside_cryptomap_dyn_20 permit ip any 69.24.64.224 255.255.255.252
ip address outside 208.42.237.126 255.255.255.248
ip address inside 69.24.64.1 255.255.240.0
ip verify reverse-path interface outside
ip verify reverse-path interface inside
ip audit name Attack attack action alarm drop reset
ip audit name Info info action alarm
ip audit interface outside Info
ip audit interface outside Attack
ip audit interface inside Info
ip audit interface inside Attack
ip audit info action alarm
ip audit attack action alarm drop reset
ip local pool VPN 69.24.64.225-69.24.64.226
nat (inside) 0 access-list inside_outbound_nat0_acl
static (inside,outside) 69.24.64.0 69.24.64.0 netmask 255.255.240.0 0 0
access-group 101 in interface outside
route outside 0.0.0.0 0.0.0.0 64.78.145.81 0
route outside 0.0.0.0 0.0.0.0 208.42.237.121 1
vpdn group GearHost accept dialin pptp
vpdn group GearHost ppp authentication pap
vpdn group GearHost ppp authentication chap
vpdn group GearHost ppp authentication mschap
vpdn group GearHost ppp encryption mppe auto required
vpdn group GearHost client configuration address local VPN
vpdn group GearHost client configuration dns 69.24.64.210
vpdn group GearHost pptp echo 60
vpdn group GearHost client authentication local
vpdn username VPNUser password ******
vpdn enable outside
vpdn enable inside
vpnclient server 69.24.64.1
vpnclient mode network-extension-mode
vpnclient vpngroup something password ******
vpnclient username something password ******
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12261302
First thing to rule out:
  given  >ip address inside 69.24.64.1
Is this the default gateway setting or all the hosts on the lan that you are trying to connec to?

Holy cow, Batman! You've completely bypassed all the security that the PIX should be providing you!
>static (inside,outside) 69.24.64.0 69.24.64.0 netmask 255.255.240.0 0 0
>access-list 101 permit tcp any any
>access-list 101 permit udp any any
>access-list 101 permit icmp any any

You don't need to enable vpdn on the inside:
   >vpdn enable inside

You have competing default gateways out:
  >route outside 0.0.0.0 0.0.0.0 64.78.145.81 0  <- I would remove this
  >route outside 0.0.0.0 0.0.0.0 208.42.237.121 1  <- keep this


0
 

Author Comment

by:rkekos
ID: 12261367
69.24.64.1 is our default gateway for all the internal network equipment.  All our equipment internal is on a /19 of that block.

:-) We don't use this PIX for any security right now (that's what I'll be working on next month).  We're migrating to PIX from our current firewall and ids systems.

Thanks for the note on vpdn (inside) and the competing gateway out...
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12261530
It appears that all the pieces are in place..
Have you tried setting up the client - check the box [x] Use Default Gateway on remote network?

Try setting up a global, just for kicks, even though you are not using NAT at all yet...

global (outside) 1 interface
0
 

Author Comment

by:rkekos
ID: 12261640
When I check the box [x] Use Default Gateway on remote network I can't get anything from my network or anyone else.  When I uncheck the box I get everything BUT my own network (69.24.64.0/19).
0
 

Author Comment

by:rkekos
ID: 12261644
Also the global (outside) 1 interface command didn't work either.
0
 
LVL 79

Accepted Solution

by:
lrmoore earned 500 total points
ID: 12261908
Ok, the first behavior is what I expected..

Let's try this. Let's give the VPN pool an entirely different subnet:

 ip local pool VPNTEST 192.168.123.225-192.168.123.226
 access-list inside_outbound_nat0_acl permit ip 69.24.64.0 255.255.240.0 192.168.123.224 255.255.255.252
 vpdn group GearHost client configuration address local VPNTEST

Now, if you set the client up with the box checked to use default gateway.... I would expect just the opposite - that you can connect to anything on the remote network, but not the Internet

BTW, you are trying this from a client that really is outside the network, right?
I had to ask....


0
 
LVL 23

Expert Comment

by:Tim Holman
ID: 12265890
0
 

Author Comment

by:rkekos
ID: 12278067
This is nat though?  Is that what I want?
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12278124
This is NOT using NAT. The configuration items below bypass NAT between the local subnet and the VPN client subnet:

>access-list inside_outbound_nat0_acl permit ip 69.24.64.0 255.255.240.0 192.168.123.224 255.255.255.252
>nat (inside) 0 access-list inside_outbound_nat0_acl
0
 

Author Comment

by:rkekos
ID: 12278371
I was referring to "ip local pool VPNTEST 192.168.123.225-192.168.123.226" or was this just an example to replace with my real IP range?  Sorry I wish I knew more about this!  Yes I am testing this from a remote location as well :-).
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12278502
What this does is set up a completely different IP address range that you can use for VPN clients, different from your local LAN, and it does not have to be a public IP range. You can use exactly what I posted. You don't have to nat between the local lan and the VPN clients because the traffic does not need to be translated because it only traverses the secure tunnel...
0
 

Author Comment

by:rkekos
ID: 12278705
Very neat.  That seems to have worked but with a problem I think.  When setup without checking the "Use Default Gateway on remote network" option it seems everything goes over just fine on my local office IP, even when talking with computers within our 69.24.64.0/19 range.  If I uncheck that box then I can't get to anything.  My question is can I setup my VPN to talk over my office connection (no VPN) to all computers outside my network but when talking with any computers within my network go over the VPN tunnel.  When using the Cisco client this was easy to setup ... I must be missing something.
0
 

Author Comment

by:rkekos
ID: 12278730
Another quick note ... when I do check the "Use Default Gateway on remote network" I CAN get into any machine within my network but no machine outside of it (ie www.google.com).  When unchecked I get to everything (internal or not) but over my office IP (is it working and just encrypting when talking with an internal computer)?
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12278866
OK, now we have exactly as I expected. Now you have just the opposite condition, with "use default getaway" checked, you can now get to anything on your remote network, just not anything else.
uncheck it and you get to everything except your remote network...

Now we have a conundrum..
Yes, it is so much easier to just use the Cisco VPN client with "split-tunneling"
Microsoft has no such feature. It's all or nothing.

Do you have anything like this in your config?
   sysopt noproxyarp inside


0
 

Author Comment

by:rkekos
ID: 12279232
Geez ... that should of been my first question then.  This way users can get the performance (no encryption) when viewing any non-internal network but use the VPN only when accessing internal resources.  If this is the case then maybe I should just stick with the cisco client.  I didn't want to because I like using built in Windows features.

No I don't have anything related to "sysopt noproxyarp inside".

Well thanks for all the help.  With all this it sounds like I need to go back to using the cisco client.  I'll award the points and thanks very much lrmoore for your help, your very helpful and patient!!!
0
 
LVL 79

Expert Comment

by:lrmoore
ID: 12279329
Glad to help. Sometimes using the built-in features is the best solution, but not always.
You do have another option - use IPSEC policies on workstations that terminate on the PIX....
This uses native Windows and IPSEC encryption to tunnel traffic to a remote network, while all the normal Internet activity bypasses the tunnel.
Background for the policy feature...
http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a00800b12b5.shtml

I have actually implemented this feature from Win2000 Server and from XP client to PIX FW and I know it works.

Still, I think that for remote users, the VPN client is the way to go. So much simpler to set up..

0

Featured Post

Windows Server 2016: All you need to know

Learn about Hyper-V features that increase functionality and usability of Microsoft Windows Server 2016. Also, throughout this eBook, you’ll find some basic PowerShell examples that will help you leverage the scripts in your environments!

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Suggested Solutions

Title # Comments Views Activity
Config NAT/PAT while having sub interface config on router. 8 33
ip igmp join-group 8 72
Cisco router external connection issues. 6 34
Cisco 3650x ACL 8 9
If you have an ASA5510 then this sort of thing would be better handled with a CSC Module, however on an ASA5505 thats not an option, and if you want to throw in a quick solution to stop your staff going to facebook during work time, then this is the…
Do you have a windows based Checkpoint SmartCenter for centralized Checkpoint management?  Have you ever backed up the firewall policy residing on the SmartCenter?  If you have then you know the hassles of connecting to the server, doing an upgrade_…
Both in life and business – not all partnerships are created equal. As the demand for cloud services increases, so do the number of self-proclaimed cloud partners. Asking the right questions up front in the partnership, will enable both parties …
As a trusted technology advisor to your customers you are likely getting the daily question of, ‘should I put this in the cloud?’ As customer demands for cloud services increases, companies will see a shift from traditional buying patterns to new…

733 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question