Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Remote PPTP Users cannot Connect to Remote Site Via HQ

Okay, I have a PIX 506E at my HQ. At the HQ we have 2 subnets, 192.168.5.0/24 and 192.168.2.0/24. We also have a remote site that is connected via an IPSec tunnel on a VPN 3000, 192.168.0.0/24. When remote users connect from the field, they connect via PPTP, and get assigned addresses from a local pool of 192.168.6.0/24. The remote users can access resources on 192.168.5.0/24 and 192.168.2.0.24. The remote site can access resources on both 192.168.5.0/24 and 192.168.2.0/24. The problem is, remote users need to access the remote site as well, but they cannot. Here is my config (10.x.y.z represents public network addresses):

PIX Version 6.3(1)

interface ethernet0 auto

interface ethernet1 auto

nameif ethernet0 outside security0

nameif ethernet1 inside security100

enable password MyEncryptedPassword encrypted

passwd MyEncryptedPassword encrypted

hostname pixfirewall

domain-name corporate.local

fixup protocol ftp 21

fixup protocol h323 h225 1720

fixup protocol h323 ras 1718-1719

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

fixup protocol smtp 25

fixup protocol sqlnet 1521

names

access-list 120 permit ip 192.168.6.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list 100 permit ip 192.168.5.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list 100 permit ip 192.168.2.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list 100 permit ip 192.168.0.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list 100 permit ip 192.168.0.0 255.255.255.0 192.168.5.0 255.255.255.0

access-list 100 permit ip 192.168.5.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list 100 permit ip 192.168.2.0 255.255.255.0 192.168.5.0 255.255.255.0

access-list 100 permit ip 192.168.6.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list 100 permit ip 192.168.0.0 255.255.255.0 192.168.6.0 255.255.255.0

access-list nonat permit ip 192.168.0.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list nonat permit ip 192.168.0.0 255.255.255.0 192.168.5.0 255.255.255.0

access-list nonat permit ip 192.168.2.0 255.255.255.0 192.168.5.0 255.255.255.0

access-list nonat permit ip 192.168.2.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list nonat permit ip 192.168.5.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list nonat permit ip 192.168.5.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list nonat permit ip 192.168.5.0 255.255.255.0 192.168.0.0 255.255.0.0

access-list nonat permit ip 192.168.0.0 255.255.255.0 192.168.6.0 255.255.255.0

access-list nonat permit ip 192.168.2.0 255.255.255.0 192.168.6.0 255.255.255.0

access-list nonat permit ip 192.168.5.0 255.255.255.0 192.168.6.0 255.255.255.0

access-list nonat permit ip 192.168.6.0 255.255.255.0 192.168.0.0 255.255.255.0

access-list nonat permit ip 192.168.6.0 255.255.255.0 192.168.2.0 255.255.255.0

access-list nonat permit ip 192.168.6.0 255.255.255.0 192.168.5.0 255.255.255.0

pager lines 24

logging on

logging standby

logging console emergencies

logging monitor emergencies

mtu outside 1500

mtu inside 1500

ip address outside w.x.y.130 255.255.255.128

ip address inside 192.168.5.6 255.255.255.0

ip audit info action alarm

ip audit attack action alarm

ip local pool remote 192.168.6.1-192.168.6.254

pdm history enable

arp timeout 14400

global (outside) 1 interface

nat (outside) 0 access-list 120

nat (inside) 0 access-list nonat

nat (inside) 1 0.0.0.0 0.0.0.0 0 0

static (inside,outside) 68.248.179.131 192.168.5.192 netmask 255.255.255.255 0 0

conduit permit tcp host 68.248.179.131 eq smtp any

conduit permit tcp host 68.248.179.131 eq www any

conduit permit tcp host 68.248.179.131 eq https any

conduit permit tcp host 68.248.179.131 eq ssh any

conduit permit tcp host 68.248.179.131 eq domain any

conduit permit udp host 68.248.179.131 eq domain any

route outside 0.0.0.0 0.0.0.0 w.x.y.129 1

route inside 192.168.2.0 255.255.255.0 192.168.5.1 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 radius-authport 1812

aaa-server radius-acctport 1813

aaa-server TACACS+ protocol tacacs+

aaa-server RADIUS protocol radius

aaa-server LOCAL protocol local

aaa-server sso protocol radius

aaa-server sso (inside) host 192.168.5.3 MySecretPhrase timeout 15

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 ukset esp-3des esp-md5-hmac

crypto map ukmap 10 ipsec-isakmp

crypto map ukmap 10 match address 100

crypto map ukmap 10 set peer 10.1.1.210

crypto map ukmap 10 set transform-set ukset

crypto map ukmap interface outside

isakmp enable outside

isakmp key ******** address 10.1.1.210 netmask 255.255.255.255

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

telnet timeout 5

ssh 192.168.5.0 255.255.255.0 inside

ssh timeout 10

console timeout 0

vpdn group remote accept dialin pptp

vpdn group remote ppp authentication mschap

vpdn group remote ppp encryption mppe 40

vpdn group remote client configuration address local remote

vpdn group remote client configuration dns 192.168.5.194

vpdn group remote client authentication aaa sso

vpdn group remote pptp echo 60

vpdn enable outside

terminal width 80

11 REPLIES
Cisco Employee

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

You can't do this with the PIX. The PIX won't send traffic back out the same interface it came in on, which includes traffic coming via PPTP and then going back out via IPSec.

Only way to do it would be to set up a separate interface for your L2L tunnels, and have your PPTP users come in on the outside interface (as seen here http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080103ed0.shtml), but since you have a 506 with only two interfaces you can't do this either.

Sorry, no way around it currently. V7 software due out later this year will resolve this , but for the moment you can't do it. You'll have to get your clients to connect directly to the other site.

New Member

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

Well, I have a 515E that I am about to replace the 506E with, and the 506E will go to another remote site. The 515E has 3 ports, but I was going to use that for a DMZ for my WLAN. I guess I could get another card and upgrade to the UR version of the PIX OS later.

Silver

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

If you use Pix version 6.3, you can create logical interfaces with dot1q encapsulation. This means you can create two "outside" interfaces and terminate the VPNs on different interfaces to allow spoke-to-spoke traffic. Note that this feature is only available on 515 and up. (not 506 or 501).

The R version of the Pix allows for 5 total interfaces. Maximum of 3 can be physical.

New Member

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

That is great. You just saved me from spending more of my budget. Now I will be able to get a modular switch later in the year :) Do you happen to have an example of this configuration?

Thanks

Silver

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

This is the closest example Cisco has. It really isn't any different if you ignore the interface names. The functional part important is that tunnel traffic from one interface can leave and go out another tunnel interface.

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094840.shtml

New Member

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

Well, I tried to assign the IPs to the 2 interfaces on the outside, and it says I cannot assign an ip that is on the same subnet as another interface

New Member

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

I looked at the config again, from the first example, and there are two subnets between the router and the pix, so I am going to do some dot1q with the 1721 router I have as well, and all will be good. I will report success if it is successful.

Silver

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

Like a router, a firewall cannot have two interfaces on the same subnet. How would it make decisions on how to forward traffic?

The two interfaces must have different subnets. This can be accomplished by splitting your current public subnet or even by using private addresses and NAT. PPTP will work with NAT but not PAT.

New Member

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

Okay, I created two subnets, implemented dot1q trunking, and everything is cool. As per the first config mentioned, I setup a static route for the other ipsec end-point to be routed out that interface rather than the default route, but I am unable to reach the host, I have a call into TAC.

Silver

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

How are you handling NAT? Don't forget that you'll need new NAT entries for the new interface and destionations, probably a [nat 0] statement.

Are you using [sysopt permit-pptp]? If not, you'll also need ACL entries on that interface.

Do you have overlapping subnets?

Do the far side know to use the tunnel for the traffic in question?

New Member

Re: Remote PPTP Users cannot Connect to Remote Site Via HQ

Okay, there is success. The biggest issues to keep in mind here is that you have two "outside" interfaces. These two interfaces are on different subnets, both in the public address space, attached to the Internet. I resolved this by using dot1q between my router and pix, this allowed logical interfaces. The second thing that I had to worry about was routing. The second "outside" interface could not ping anywhere outside its subnet. I had to create a route to the network(s) that need(s) access to the interface for tunnel termination. Lastly, allowing remote users to access the data on the other networks attached via IPSec tunnels... You have to create a nat 0 for you "outside" interface, but do not name it "outside" because you may need to raise the security of that interface. Anyhow, all is working, in an extremely complex setup, as I am implementing VLANs and dot1q, and RADIUS for authentication, on top of everyting in that config. Thanks to all that helped.

134
Views
0
Helpful
11
Replies
CreatePlease login to create content