Unable to PPTP through NAT on Cisco 881
- by MasterRoot24
I'm trying to connect to a PPTP server which is sat behind a Cisco 881 NAT router. The server is running Ubuntu Server 12.04 and is running Poptop pptpd as the PPTP daemon listening for connections.
As discussed in my other question, I'm trying to setup a Cisco 881 router to replace my old Linksys WAG320N. This same server and WAN connection worked fine with the WAG320N with no special configuration, other than allowing 1723 in through the firewall.
On the Cisco 881, I'm using the newer ip nat enable or NAT NVI to setup static routes in through the firewall for the services running behind the router. My reason being that I can't run another copy of my live DNS domains internally with local IP addresses in. For the purposes of this question, though, I have rebuilt the router with ip nat inside/outside style NAT'ing, but this issue is still apparent. HTTP/SMTP/IMAP etc. all work ok from both the WAN and LAN interfaces of the router. I'm only having issues with SIP (see other question) and PPTP.
My issue is that the GRE doesn't appear to be passing through NAT correctly and one end of the connection is not receiving GRE traffic when it should be, so the server hangs up the connection.
Here's an example of /var/log/syslog with debug enabled in /etc/pptpd.conf:
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: MGR: Launching /usr/sbin/pptpctrl to handle client
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: local address = 192.168.1.50
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: remote address = 192.168.1.51
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: pppd options file = /etc/ppp/pptpd-options
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Client 82.132.248.216 control connection started
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Received PPTP Control Message (type: 1)
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Made a START CTRL CONN RPLY packet
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: I wrote 156 bytes to the client.
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Sent packet to client
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Received PPTP Control Message (type: 7)
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Set parameters to 100000000 maxbps, 64 window size
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Made a OUT CALL RPLY packet
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Starting call (launching pppd, opening GRE)
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: pty_fd = 6
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: tty_fd = 7
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: I wrote 32 bytes to the client.
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: CTRL: Sent packet to client
Dec 11 21:06:30 <HOSTNAME> pptpd[22627]: CTRL (PPPD Launcher): program binary = /usr/sbin/pppd
Dec 11 21:06:30 <HOSTNAME> pptpd[22627]: CTRL (PPPD Launcher): local address = 192.168.1.50
Dec 11 21:06:30 <HOSTNAME> pptpd[22627]: CTRL (PPPD Launcher): remote address = 192.168.1.51
Dec 11 21:06:30 <HOSTNAME> pppd[22627]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded.
Dec 11 21:06:30 <HOSTNAME> pppd[22627]: pppd 2.4.5 started by root, uid 0
Dec 11 21:06:30 <HOSTNAME> pppd[22627]: Using interface ppp0
Dec 11 21:06:30 <HOSTNAME> pppd[22627]: Connect: ppp0 <--> /dev/pts/3
Dec 11 21:06:30 <HOSTNAME> pptpd[22626]: GRE: Bad checksum from pppd.
Dec 11 21:06:31 <HOSTNAME> pptpd[22626]: CTRL: Received PPTP Control Message (type: 15)
Dec 11 21:06:31 <HOSTNAME> pptpd[22626]: CTRL: Got a SET LINK INFO packet with standard ACCMs
Dec 11 21:07:00 <HOSTNAME> pppd[22627]: LCP: timeout sending Config-Requests
Dec 11 21:07:00 <HOSTNAME> pppd[22627]: Connection terminated.
Dec 11 21:07:00 <HOSTNAME> avahi-daemon[1042]: Withdrawing workstation service for ppp0.
Dec 11 21:07:00 <HOSTNAME> pppd[22627]: Modem hangup
Dec 11 21:07:00 <HOSTNAME> pppd[22627]: Exit.
Dec 11 21:07:00 <HOSTNAME> pptpd[22626]: GRE: read(fd=6,buffer=6075a0,len=8196) from PTY failed: status = -1 error = Input/output error, usually caused by unexpected termination of pppd, check option syntax and pppd logs
Dec 11 21:07:00 <HOSTNAME> pptpd[22626]: CTRL: PTY read or GRE write failed (pty,gre)=(6,7)
Dec 11 21:07:00 <HOSTNAME> pptpd[22626]: CTRL: Reaping child PPP[22627]
Dec 11 21:07:00 <HOSTNAME> pptpd[22626]: CTRL: Client 82.132.248.216 control connection finished
Dec 11 21:07:00 <HOSTNAME> pptpd[22626]: CTRL: Exiting now
Dec 11 21:07:00 <HOSTNAME> pptpd[5803]: MGR: Reaped child 22626
As far as Cisco are concerned, all I need is ip nat source static tcp <SERVER LAN IP> 1723 interface FastEthernet4 1723 but of course this doesn't seem to the be helping the GRE traffic through as it should.
Trying the connection to the LAN IP of the server from the same LAN as the server (behind the router), the PPTP connection works fine, so I'm confident that the server's config is ok. Furthermore, all I needed on my WAG320N was to open 1723 in the firewall.
Here's my current router config:
!
! Last configuration change at 20:20:15 UTC Tue Dec 11 2012 by xxx
version 15.2
no service pad
service timestamps debug datetime msec
service timestamps log datetime msec
service password-encryption
!
hostname xxx
!
boot-start-marker
boot-end-marker
!
!
enable secret 4 xxxx
!
aaa new-model
!
!
aaa authentication login local_auth local
!
!
!
!
!
aaa session-id common
!
memory-size iomem 10
!
crypto pki trustpoint TP-self-signed-xxx
enrollment selfsigned
subject-name cn=IOS-Self-Signed-Certificate-xxx
revocation-check none
rsakeypair TP-self-signed-xxx
!
!
crypto pki certificate chain TP-self-signed-xxx
certificate self-signed 01
xxx
quit
ip gratuitous-arps
ip auth-proxy max-login-attempts 5
ip admission max-login-attempts 5
!
!
!
!
!
ip domain list dmz.xxx.local
ip domain list xxx.local
ip domain name dmz.xxx.local
ip name-server 192.168.1.x
ip cef
login block-for 3 attempts 3 within 3
no ipv6 cef
!
!
multilink bundle-name authenticated
license udi pid CISCO881-SEC-K9 sn xxx
!
!
username admin privilege 15 secret 4 xxx
username joe secret 4 xxx
!
!
!
!
!
ip ssh time-out 60
!
!
!
!
!
!
!
!
!
interface FastEthernet0
no ip address
!
interface FastEthernet1
no ip address
!
interface FastEthernet2
no ip address
!
interface FastEthernet3
switchport access vlan 2
no ip address
!
interface FastEthernet4
ip address dhcp
ip nat enable
duplex auto
speed auto
!
interface Vlan1
ip address 192.168.1.x 255.255.255.0
no ip redirects
no ip unreachables
no ip proxy-arp
ip nat enable
!
interface Vlan2
ip address 192.168.0.x 255.255.255.0
!
ip forward-protocol nd
ip http server
ip http access-class 1
ip http authentication local
ip http secure-server
!
!
ip nat source list 1 interface FastEthernet4 overload
ip nat source list 2 interface FastEthernet4 overload
ip nat source static tcp 192.168.1.x 1723 interface FastEthernet4 1723
!
!
access-list 1 permit 192.168.0.0 0.0.0.255
access-list 2 permit 192.168.1.0 0.0.0.255
!
!
!
!
control-plane
!
!
banner motd
Authorized Access only
!
line con 0
exec-timeout 15 0
login authentication local_auth
line aux 0
exec-timeout 15 0
login authentication local_auth
line vty 0 4
access-class 2 in
login authentication local_auth
length 0
transport input all
!
!
end
UPDATE 16/12/2012:
The only progress that I have been able to make on this issue is that I'm confident that the issue is caused by the GRE tunnels (which are required for the PPTP connection to complete) are being blocked. When attempting a connection, I can see in show ip nat nvi translations that both a TCP translation on 1723 is setup and also a GRE translation is setup also. I appear to be able to see GRE related packets on the LAN that the server is on, so I am lead to believe that the server is sending(?) GRE packets, however running Wireshark on a client PC when attempting a connection shows absolutely no GRE packets.
Whilst there are no configuration directives in my config posted above (that I can pin point) which would specifically block them, it would appear that the GRE packets are not being allowed in/out of the router's firewall, even though a NAT translation entry is setup to the server's LAN address. Would anyone be able to provide me with some help to ensure that GRE packets are not blocked by the router's firewall, so that this can be ruled out as a possible issue please?
