GRE setup in Cisco for mobile VPN users?

[CorbinMyMan]

I'm using an iPAQ 6505 with Windows Mobile 2003. I've configured VPN on it to connect to my office network. I click CONNECT and it dials up the data provider and connects and then tried connecting to the vpn. It connects to the data provider and gets online no prob, but throws an error when trying to hit my vpn server. I checked my vpn server Event lot and it gave me an errorID 20209 which states:

A connection between the VPN server and the VPN client xx.xx.xx.xxx has been established, but the VPN connection cannot be completed. The most common cause for this is that a firewall or router between the VPN server and the VPN client is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47). Verify that the firewalls and routers between your VPN server and the Internet allow GRE packets. Make sure the firewalls and routers on the user's network are also configured to allow GRE packets. If the problem persists, have the user contact the Internet service provider (ISP) to determine whether the ISP might be blocking GRE packets.


I'm certain its the cisco stopping it, but how can I configure it to allow the GRU packets?

Thanks for any help!!!

 

[CorbinMyMan]

Here's my config I just copied from the router:

Current configuration : 1396 bytes
!
version 12.3
service timestamps debug uptime
service timestamps log uptime
service password-encryption
!
hostname PARAD_CISCO1
!
logging buffered 10000 debugging
no logging console
enable password 7 xxxxxxxxxxxxx
!
memory-size iomem 25
no aaa new-model
ip subnet-zero
!
!
!
ip audit notify log
ip audit po max-events 100
ip ssh break-string
mpls ldp logging neighbor-changes
no ftp-server write-enable
!
!
!
modemcap entry usr56k:MSC=&f1s0=1
!
!
!
controller T1 0/0
framing esf
clock source internal
linecode b8zs
channel-group 0 timeslots 1-24 speed 64
!
!
interface FastEthernet0/0
ip address xx.xxx.xx.xxx 255.255.255.248
duplex auto
speed auto
!
interface Serial0/0:0
ip address xx.xxx.xx.xxx 255.255.255.252
ip access-group 101 in
!
ip classless
ip route 0.0.0.0 0.0.0.0 xx.xxx.xx.xxx
!
no ip http server
no ip http secure-server
!
access-list 101 deny ip any host xx.xxx.xx.212
access-list 101 deny ip any host xx.xxx.xx.213
access-list 101 deny ip any host xx.xxx.xx.214
access-list 101 deny ip any host xx.xxx.xx.215
access-list 101 permit ip any any
!
!
!
line con 0
exec-timeout 320 0
password 7 xxxxxxxxxxxxxxxxxxx
login
line aux 0
session-timeout 1
password 7 xxxxxxxxxxxxxxxxxx
login
modem InOut
modem autoconfigure type usr56k
transport input all
autohangup
stopbits 1
speed 115200
line vty 0 4
password 7 xxxxxxxxxxxxxxxxxxxx
login
!
!
!
end

So IF thats my configuration the GRE packets should be making it through to the firewall?

I'm not seeing ANY entries for the iPAQ IP at all when I look at my logs of my firewall.

 

[NetworkGhost]

You should be good to go. Is it possible that the FW is not logging on the rule that allows GRE in? or the Rules that allow pptp? If you VPN server sees it then it has to be going through the fw. I would make sure logging is enabled on the rules you need to track (GRE, PPTP). Are other users able to connect fine?

 

[CorbinMyMan]

Yes my normal VPN users are fine. Its only when I try to connect to VPN using my iPAQ and PocketPC2003 that I get this problem and that error in my event log of my RRAS server.

I'll triple check my firewall and keep you posted.

Thank you!

 

[CorbinMyMan]

Support from my firewall vendor claims that if a PC can connect to the vpn server then there's nothing they can do for me. They also said they offer no debugging on it...
Can you guys suggest a better firewall? That has its own spam filter built in?

The logs of the firewall aren't showing the address of the iPAQ though, is there any way to debug the cisco to show me when the packets that start with 66.209 go through an interface? and if they make it through the cisco and where they go to?

THanks again guys!

 

[NetworkGhost]

Yes.

make sure ip route-cache is disabled in the the routers interfaces.

Set up a acl


conf t
access-list 150 permit ip 66.209.0.0 0.0.255.255 any
access-list 150 permit ip any 66.209.0.0 0.0.255.255
exit
debug ip packet 150 detail
term mon

Just remember to kill the debug after. I wouldnt debug during busy hours either,

undebug all

 

[gregbeason]

Have you tried setting up a VPN from a PC to the VPN server? If you can connect to the server, then the problem is either with the iPAQ or the service provider.