8 Replies Latest reply on Feb 8, 2010 5:54 PM by rcamm

    vpn wont connect

      Hello,

       

      I can't figure out why my remote user can't connect to the SG 560.

       

      any ideas?  please and thank you

       

      Log says:

       

      Feb  5 14:07:16 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.11 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=58584 DF PROTO=TCP SPT=139 DPT=2961 WINDOW=65535 RES=0x00 ACK SYN URGP=0  
      Feb  5 14:07:16 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.5 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=34868 DF PROTO=TCP SPT=139 DPT=2964 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:07:18 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.5 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=34923 DF PROTO=TCP SPT=139 DPT=2964 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:07:19 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.11 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=58647 DF PROTO=TCP SPT=139 DPT=2961 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:07:51 pppd[8791]: pppd 2.3.8 started by (unknown), uid 0
      Feb  5 14:07:51 pppd[8791]: pppd create pidfile /var/run/ppp1.pid
      Feb  5 14:07:51 pppd[8791]: Connect: ppp1 <--> /dev/ttyp1
      Feb  5 14:07:51 pppd[8791]: Will not do PAP for user PoPToP
      Feb  5 14:07:51 pppd[8791]: Will not do CHAP for user PoPToP
      Feb  5 14:07:51 pptpd[8790]: GRE: Discarding duplicate packet

       

       

       

       

      Feb  5 14:07:54 pptpd[8790]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! 
      Feb  5 14:07:55 pppd[8791]: MSCHAP-v2 peer authentication succeeded for user
      Feb  5 14:07:55 pptpd[8790]: GRE: Discarding out of order packet
      Feb  5 14:07:55 pppd[8791]: Cannot determine ethernet address for proxy ARP
      Feb  5 14:07:55 pppd[8791]: local  IP address 192.168.0.1
      Feb  5 14:07:55 pppd[8791]: remote IP address 192.168.1.116
      Feb  5 14:07:58 ipsec: [setup] Stopping FreeS/WAN IPSEC...
      Feb  5 14:07:58 ipsec: [setup] ...FreeS/WAN IPSEC stopped
      Feb  5 14:08:01 ipsec: [setup] Stopping FreeS/WAN IPSEC...
      Feb  5 14:08:01 ipsec: [setup] ...FreeS/WAN IPSEC stopped
      Feb  5 14:08:08 kernel: Default - dropped: IN=eth1 OUT= MAC=00:d0:cf:0d:d3:5d:00:0c:86:39:b2:2e:08:00 SRC=96.17.157.47 DST=69.199.47.126 LEN=96 TOS=0x00 PREC=0x00 TTL=51 ID=0 DF PROTO=UDP SPT=3478 DPT=55791 LEN=76 
      Feb  5 14:08:17 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.11 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=58754 DF PROTO=TCP SPT=139 DPT=3056 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:08:17 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.5 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=34993 DF PROTO=TCP SPT=139 DPT=3058 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:08:20 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.11 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=58815 DF PROTO=TCP SPT=139 DPT=3056 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:08:20 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.5 DST=10.0.10.66 LEN=48 TOS=0x00 PREC=0x00 TTL=127 ID=35051 DF PROTO=TCP SPT=139 DPT=3058 WINDOW=65535 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:08:24 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.43 DST=10.0.10.90 LEN=48 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=TCP SPT=139 DPT=3602 WINDOW=5840 RES=0x00 ACK SYN URGP=0 
      Feb  5 14:08:28 pppd[8791]: CCP: timeout sending Config-Requests 
      Feb  5 14:08:32 kernel: Default - dropped: IN=eth1 OUT= MAC=00:d0:cf:0d:d3:5d:00:0c:86:39:b2:2e:08:00 SRC=74.208.5.6 DST=69.199.47.126 LEN=61 TOS=0x00 PREC=0x00 TTL=52 ID=945 DF PROTO=TCP SPT=143 DPT=4492 WINDOW=5840 RES=0x00 ACK PSH URGP=0 
      Feb  5 14:08:43 pppd[8791]: Modem hangup
      Feb  5 14:08:43 pppd[8791]: Connection terminated.
      Feb  5 14:08:43 pppd[8791]: Couldn't release PPP unit: Invalid argument
      Feb  5 14:08:43 pptpd[8790]: CTRL: Asked to free call when no call open, not handled well
      Feb  5 14:08:43 pptpd[8790]: CTRL: Could not free Call ID [admin shutdown]!
      Feb  5 14:08:43 pptpd[8790]: CTRL: Couldn't write packet to client.
      Feb  5 14:08:47 ipsec: [setup] Stopping FreeS/WAN IPSEC...
      Feb  5 14:08:47 ipsec: [setup] ...FreeS/WAN IPSEC stopped
      Feb  5 14:08:47 kernel: Invalid - dropped: IN=eth0 OUT=eth1 SRC=192.168.0.5 DST=10.0.10.66 LEN=48 TOS
        • 1. Re: vpn wont connect

          This sylog messages

           

          Feb  5 14:08:28 pppd[8791]: CCP: timeout sending Config-Requests  

          refers to a timeout on the sending of GRE packets.

          PPTP consists of a control channel on tcp 1723, and a data/config channel on GRE, IP protocol 47

          This timeout firstly may be due to a NAT device that does not perform PPTP NAT correctly as ecplained in
          KB62307 which I will include here

          The short answers is to reboot the NAT device ( probably at the user end ) and see if that resolves the issue.

           

           

          NAT devices can create challenges for a successful and reliable connection for PPTP VPN sessions. To understand the problem with PPTP and NAT, we must first understand how PPTP works in further detail.

          PPTP clients initiate all connections using TCP port 1723 which allocates session IDs for the particular connection. Once the initial handshaking is done using this port, communications switch to GRE (protocol number 47).  The initial session IDs that were setup by the TCP 1723 control connection are maintained. Then, the TCP 1723 control connection is only used for echo requests and echo replies between the client and server so that both ends know the remote end is still alive. The TCP 1723 control connection is also used to terminate the VPN connection.

          To perform NAT correctly for PPTP connections, the NAT device must be able to associate a GRE protocol connection with the correct client or server by inspecting the IDs contained in the GRE packets. It also must perform NAT on the IDs to ensure they are unique because multiple PPTP connections from different clients or servers may use the same IDs.

          Simple NAT devices will only use the IP addresses of the initiating client and the destination server when they perform the NAT translation and will not inspect the IDs inside the GRE packets.  These devices perform NAT correctly when there is only one PPTP session from any client or to any server.  However, when there are multiple PPTP sessions, these simple NAT devices are not able to associate the correct GRE connection with the correct client or server.  They will send the 2nd session's GRE packets to the incorrect client or server, as per the NAT translation table for the 1st session.

          The UTM Firewall firewall is able to inspect the session IDs inside the GRE packets and will correctly perform NAT for PPTP sessions.

          • 2. Re: vpn wont connect

            Well There occurs these similar type of problems for me too. But you can contact the service provider for this issues. They resolve your problem Soon and I have the same issue with it.

            • 3. Re: vpn wont connect

              are you suggesting something here?

               

              i appreciate the knowledge but it doesn't help me

               

              i should have my remote user reboot his router, which is his NAT device?

              • 4. Re: vpn wont connect

                You need to eliminate the NAT device as the source of the issue, no doubt at the end users end.

                 

                The easiest way may be to connect a PC directly to the ISP ( for diagnostic purposes ) rather than via the NAT device and see if that works.

                • 5. Re: vpn wont connect

                  I appreciate the help.  But think about it.  The only way to remove the NAT device, in most cases, is to remove the ability to get on the internet.  How can I have my user remove the router or modem?  I can't.  Unless a home user has a static IP, which rarely happens, this can't work.

                   

                  Or maybe I'm not getting what you mean?

                   

                  thanks

                  • 6. Re: vpn wont connect

                    Your client OS should have native PPPoE/Cable/T1 clients to connect to the internet...ie PPPoE, DHCP etc

                    • 7. Re: vpn wont connect

                      i'm sorry, but i am confused

                       

                      so you're saying that windows vista should be able to plug into the coax cable?

                       

                      i don't get it

                       

                      thank you

                      • 8. Re: vpn wont connect

                        Correct, that will not work. I did not understand you were using cable.

                         

                        When using cable, is the public IP assigned to you client PC, or the cable modem/router ?

                         

                        The other option is see if you can reproduce the same issue from another Internet connection if you have that luxury.