![[H]ard|Forum](/styles/hardforum/xenforo/logo_dark.png){kind=logo}
Hopefully someone can make a little more sense of this than I can. We have a Watchguard Firebox at our location and have a usergroup in AD that it authenticates VPN connections against. The problem is coming from one location specifically, in that I can sign in under the account from my home and other places, but the location where we need someone to VPN in can't connect.
Here is snippet 1 where it appears as if the connection is successful:
(The location that is trying to connect is 64.215.xx.xx)
And here is where it appears to drop it about 37 seconds later, but I have no idea why
I'm curious about the line:
recv call-clear-request from 64.215.xx.xx
Can anyone shed some light onto this? Thanks in advance.
Here is snippet 1 where it appears as if the connection is successful:
(The location that is trying to connect is 64.215.xx.xx)
Code:
11110816807/12/06 09:49:04 y tunneld[180] connected to 64.215.xx.xx:10564
11110817807/12/06 09:49:04 y tunneld[180] 156 bytes received from socket 13
11110818807/12/06 09:49:04 y tunneld[180] recv start-control-connection-request from 64.215.88.14
11110819807/12/06 09:49:04 y tunneld[180] sent start-control-connection-reply
11110820807/12/06 09:49:04 y tunneld[180] 168 bytes received from socket 13
11110821807/12/06 09:49:04 y tunneld[180] recv outgoing-call-request from 64.215.xx.xx
11110822807/12/06 09:49:04 y tunneld[180] gre rule added for 64.215.xx.xx
11110823807/12/06 09:49:04 y tunneld[180] spawned PPTPD with process id #751
11110824807/12/06 09:49:04 y tunneld[180] sent outgoing-call-reply
11110825807/12/06 09:49:04 y tunneld[751] starting PPTPD server
11110826807/12/06 09:49:04 y tunneld[751] pptpd
11110827807/12/06 09:49:04 y tunneld[751] silent
11110828807/12/06 09:49:04 y tunneld[751] 192.168.xxx.xxx:192.168.xxx.yyy
11110829807/12/06 09:49:04 y tunneld[751] -vj
11110830807/12/06 09:49:04 y tunneld[751] remotename
11110831807/12/06 09:49:04 y tunneld[751] 64.215.xx.xx
11110832807/12/06 09:49:04 y tunneld[751] gre
11110833807/12/06 09:49:04 y tunneld[751] 3:256
11110834807/12/06 09:49:04 y tunneld[751] channel
11110835807/12/06 09:49:04 y tunneld[751] 3
11110836807/12/06 09:49:04 y tunneld[751] +chap
11110837807/12/06 09:49:04 y tunneld[751] dns-addr
11110838807/12/06 09:49:04 y tunneld[751] 192.168.xxx.xxx
11110839807/12/06 09:49:04 y tunneld[751] dns-addr
11110840807/12/06 09:49:05 y tunneld[751] 192.168.xxx.xxx
11110841807/12/06 09:49:05 y tunneld[751] nbns-addr
11110842807/12/06 09:49:05 y tunneld[751] 192.168.xxx.xxx
11110843807/12/06 09:49:05 y tunneld[751] debug
11110844807/12/06 09:49:05 y tunneld[751] xauth
11110845807/12/06 09:49:05 y tunneld[751] radius_mschap2
11110846807/12/06 09:49:05 y tunneld[751] required_group
11110847807/12/06 09:49:05 y tunneld[751] pptp_users
11110848807/12/06 09:49:05 y tunneld[751] ccp-max-reset
11110849807/12/06 09:49:05 y tunneld[751] 257
11110850807/12/06 09:49:05 y tunneld[751] mppecomp
11110851807/12/06 09:49:05 y tunneld[751] drop
11110852807/12/06 09:49:05 y tunneld[751] nocomp
11110853807/12/06 09:49:05 y tunneld[751] stateless
11110854807/12/06 09:49:05 y tunneld[751] proxyarp
11110855807/12/06 09:49:05 y tunneld[751] setpptpmtu
11110856807/12/06 09:49:05 y tunneld[751] 1436
11110857807/12/06 09:49:05 y pptpd[751] Watchguard pptpd 2.2.0 started
11110858807/12/06 09:49:05 y pptpd[751] Using interface pptp3
11110859807/12/06 09:49:05 y kernel pptp3: daemon attached.
11110860807/12/06 09:49:05 y pptpd[751] getting restart socket: pptp.751
11110861807/12/06 09:49:05 y pptpd[751] Connect: pptp3 [3] <--> 64.215.xx.xx
11110862807/12/06 09:49:05 y tunneld[180] 24 bytes received from socket 13
11110863807/12/06 09:49:05 y tunneld[180] recv set-link-info from 64.215.xx.xx
11110864807/12/06 09:49:05 y tunneld[180] sent set-link-infoAnd here is where it appears to drop it about 37 seconds later, but I have no idea why
Code:
11111345807/12/06 09:49:42 y tunneld[180] 16 bytes received from socket 13
11111346807/12/06 09:49:42 y tunneld[180] recv call-clear-request from 64.215.xx.xx
11111347807/12/06 09:49:42 y tunneld[180] killing child pid 751
11111348807/12/06 09:49:42 y tunneld[180] saving channel 192.168.xxx.xxx:192.168.yyy.yyy to new fd 13 list
11111349807/12/06 09:49:42 y tunneld[180] sent call-disconnect-notify
11111350807/12/06 09:49:42 y pptpd[751] Terminating on signal 2.
11111351807/12/06 09:49:42 y pptpd[751] Connection terminated.
11111352807/12/06 09:49:42 y pptpd[751] Persist flag not set, so we are exiting.
11111353807/12/06 09:49:42 y pptpd[751] removing socket: /tmp/restart_uds/pptp.751
11111354807/12/06 09:49:42 y kernel pptp3: pptp_sock_close
11111355807/12/06 09:49:42 y pptpd[751] CHAP will not try to logout user
11111356807/12/06 09:49:42 y pptpd[751] Exit.
11111357807/12/06 09:49:42 y tunneld[180] rcvd SIGCHLD--ignoring
11111358807/12/06 09:49:42 y tunneld[180] child pid 751 died
11111359807/12/06 09:49:42 y tunneld[180] setting channel 192.168.xxx.xxx:192.168.yyy.yyy to be re-used
11111360807/12/06 09:49:42 y tunneld[180] removing 64.215.xx.xx from active list
11111361807/12/06 09:49:42 y tunneld[180] closing fd 13I'm curious about the line:
recv call-clear-request from 64.215.xx.xx
Can anyone shed some light onto this? Thanks in advance.