I'm in this same boat. I have gone through almost exactly the same frustrations that ForumKid has gone through and come to the same understanding. I have a PIX 520 and also need the image for 6.3. Can someone send that to me as well??? Thx. aharper@escient.com
I have done this now:
access-list acl_out permit gre host <pptp server> host <public static IP that is available in our block (not outside int. address)>
static (inside,outside) <public static IP that is available in our block (not outside int. address)> 192.168.1.50 netmask 255.255.255.255 0 0
I can connect to the PPTP server. But it just hangs on verifiying password. No syslog errors. No nothing..
This public outside address available in your block - is it on the outside range of THE PIX (NOT the router)?
Can you please post something with ip addresses in it, just change one of the octets or something, so we can see if you're using public ip addresses, private ip addresses or what.
Please post the outside ip of your pix, and the interface addresses of your router, they don't have to be the ACTUAL addresses, just something we can figure out what you're doing.
eg,
if the outside address of your pix is 62.25.50.15, just post something like 62.25.40.15 instead
At the moment it's really unclear what ip you're using
You can obtain the latest image for the pix by contacting cisco and buying it, or if you have Smartnet on your cisco device you can download it.
FYI: This is my router access-list. NOt sure if that is causing any issues.....
access-list 1 deny any
access-list 101 deny ip 65.198.124.64 0.0.0.7 any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip any host 65.198.124.65
access-list 101 permit icmp any 65.198.124.64 0.0.0.7 echo-reply
access-list 101 permit tcp any any established
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq www
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq 443
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq smtp
access-list 101 permit udp any eq domain any
Your router has access lists on it ... right - you know that access lists deny everything that's not explicitly allowed? Can you see a rule on the router allowing GRE traffic?
I'm assuming the router is ip-unnumbered, but maybe I'm wrong to make assumptions ... Any danger of you posting the router config?
This is like a jigsaw puzzle where you get given a piece a day
I was admired by you trying to help ForumKid with his config.. I was wondering if I may send you my config and question concerning a PIX 501/VPN issue.. I already posted it on this forum but haven't heard back from anyone yet.. Just let me know if thats ok.. i also have the full config on the post I sent..
thx
I wish I had a way to email you directly with this post but here goes anyway..
I had this PIX deployed at customer site which was configured by someone that doesn't work here anymore.. I'd like certain people including myself to be able to VPN to it from our remote office.. I will post the config and am wondering what I need to edit in order for this functionality to happen. It doesn't look like there is an outside address configured on the PIX so my VPN client needs an outside address interface (entry) to be inputted.. Also, this PIX is sitting behind a cable modem where addresses are probably assigned via DHCP from what I gather. Well, here's the config, if anyone can shed some light, that would be great!
Yes I understand and sorry for dragging this out. I do not have an explicit acl for allowing gre traffic into my router.
Here is my router config if it helps.
Current configuration:
!
version 12.1
service timestamps debug uptime
service timestamps log uptime
no service password-encryption
!
hostname xxx
!
enable password xxx
!
!
!
!
!
ip subnet-zero
no ip finger
ip domain-name xxx.NET
ip name-server xxx.xxx.xxx.xxx
!
no ip bootp server
!
!
!
interface FastEthernet0/0
description To Office FastEthernet
ip address 65.198.124.65 255.255.255.248
duplex auto
speed auto
!
interface Serial0/0
description To xxx
bandwidth 1536
no ip address
encapsulation frame-relay IETF
no fair-queue
service-module t1 clock source internal
frame-relay lmi-type ansi
!
interface Serial0/0.1 point-to-point
bandwidth 1536
ip unnumbered FastEthernet0/0
ip access-group 101 in
frame-relay interface-dlci 500 IETF
!
ip classless
ip route 0.0.0.0 0.0.0.0 Serial0/0.1
no ip http server
!
access-list 1 deny any
access-list 101 deny ip 65.198.124.64 0.0.0.7 any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip any host 65.198.124.65
access-list 101 permit icmp any 65.198.124.64 0.0.0.7 echo-reply
access-list 101 permit tcp any any established
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq www
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq 443
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq smtp
access-list 101 permit udp any eq domain any
snmp-server engineID local 0000000902000030854D17C0
snmp-server community 6db68826a3 RO
snmp-server packetsize 2048
snmp-server enable traps snmp
!
!
line con 0
password xxx
login
transport preferred none
transport input none
line aux 0
password xxx
login
modem InOut
transport preferred none
transport input all
transport output pad v120 telnet rlogin udptn
stopbits 1
flowcontrol hardware
line vty 0 4
access-class 1 in
login
transport preferred none
!
no scheduler allocate
end
It sounds like version 6.3 for the PIX 5xx firewall is the best fix for the protocol 47 problem. My effort to download the upgrade from Cisco was unsuccessful. It appears I must be a reseller or Cisco engineer or something to download from their site. Is this correct?
I'm running a 501 and also getting the protocol 47 failure when I attempt to establish a VPN connection through the 501 to another host. I "discovered" I'm running version 6.1(1). It sounds like upgrading to 6.3 is the only solution since, in one case, the IP address of the VPN I'll be trying to connect to is dynamic. Inbound VPN has been working fine.
Well adding this to my router access-list fixes the problem
access-list 101 permit gre any any
although this doesnt work
access-list 101 permit gre host <pptp> any
this doesnt work
access-list 101 permit gre any host 65.198.124.64
So as far at the protocol 47 thing, check my pix config. If you set it up like that it will work. But my last question on this topic is why do i have to have my router acl opened to "any any"? That is a risk.
Okay, I think we're really nearly there mate. Your router is ip-unnumbered, but its acl blocks gre traffic from the pptp server coming back to the pix. I think all you're going to need now is a line like
access-list 101 permit gre host <pptp server> host 65.198.124.68
Where 65.198.124.68 is the static address you used to translate your internal 192.168.1.50 machine.
So your access list on the router ends up looking something like;
access-list 101 deny ip 65.198.124.64 0.0.0.7 any
access-list 101 deny ip 10.0.0.0 0.255.255.255 any
access-list 101 deny ip 172.16.0.0 0.15.255.255 any
access-list 101 deny ip 192.168.0.0 0.0.255.255 any
access-list 101 deny ip any host 65.198.124.65
access-list 101 permit icmp any 65.198.124.64 0.0.0.7 echo-reply
access-list 101 permit tcp any any established
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq www
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq 443
access-list 101 permit tcp any 65.198.124.64 0.0.0.7 eq smtp
access-list 101 permit udp any eq domain any
access-list 101 permit gre host <pptp server> host 65.198.124.68
Also, although it's not relevant to the problem you've got, the subnet mask of your outside interface of the pix is wrong. The line should read
ip address outside 65.198.124.66 255.255.255.248
rather than using 255.255.255.0. This won't affect this problem at all, but I *think* it will mean that your local machines can't reach websites on the 65.198.124.0 range outside of your 65.198.124.64 - .71 range, because the pix will think they're on the same subnet as it's outside address, so it will arp for them, rather than forwarding that traffic to the router. You could easily test that by trying to get to websites on the 65.198.124.0 range.
I *think* this should now work ... but I may have missed something ...
The acl works great. Everything is working excellent now. I however didnt change my subnet of my outside interface. I will run the test that you stated. Although I semi-understand why it should be 255.255.255.248. It makes sense. I will change that off hours just incase that causes an issue.
I know your an ace with VPN concepts and was wondering if you can take a glance at the thread I sent you within this forum.. I didn't know how else to reach you but you'll find my post within this thread afew entires up.. thanks bud! If you have time ofcourse..
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.