Koozali.org: home of the SME Server
Obsolete Releases => SME Server 8.x => Topic started by: apmuthu on April 13, 2013, 08:20:15 AM
-
A fully yummed SME8 running in Server and Gateway mode with the WAN as DHCP Public IP has PPTP VPN Server running with active users and incoming VPN works OK.
A WinXP on the LAN side of the SME8 cannot connect to a non-SME PPTP VPN Server on the internet but can connect to other SME8 PPTP VPN Servers.
Any fix?
-
yes, fix the no-SME PPTP VPN server..
-
The non-SME8 PPTP VPN Server is a pfSense box - tried pfSense v2.0.2 and 2.1 beta as well. Even latest v1.8 b537 of m0n0wall also fails to be compatible with SME8.
Is there anything specific to be put into pfSense / m0n0wall for it to be accessible from behind an SME8 server-cum-gateway ?
-
apmuthu
did you take a look at pfsense/m0n0wall logs?
what is the error message on XP client?
did you try to bypass SME gateway? if so, does it work?
how is connected pfsense/m0n0wall? router? modem? how?
IMHO it could be a MTU issue on m0n0/pfsense side.. you should dig into their log and probably ask on their forums.. SME seems not to be involved in the issue (XP can connect to other pptp servers..)
HTH
-
Works if SME GW is bypassed.
pfSense 2.1 Logs in reverse chronological order for a connection from WinXP_SP3 behind SME8:
1.2.3.4 is Global WAN IP of SME8
aa:bb:cc:dd:ee:ff is the MAC Address of the pfSense's WAN Port
pfSense v2.1B0 Time PPTP from SME8 Log
==========================================
2013-04-13 15:13:39 pptps: pptp0: killing connection with 1.2.3.4 1201
2013-04-13 15:13:39 pptps: pptp0: closing connection with 1.2.3.4 1201
2013-04-13 15:13:39 pptps: [pt0] LCP: state change Closed --> Initial
2013-04-13 15:13:39 pptps: [pt0] LCP: Down event
2013-04-13 15:13:39 pptps: [pt0] LCP: state change Stopped --> Closed
2013-04-13 15:13:39 pptps: [pt0] LCP: Close event
2013-04-13 15:13:39 pptps: [pt0] link: DOWN event
2013-04-13 15:13:39 pptps: [pt0] PPTP call terminated
2013-04-13 15:13:39 pptps: pptp0-0: killing channel
2013-04-13 15:13:39 pptps: pptp0-0: clearing call
2013-04-13 15:13:39 pptps: [pt0] LCP: LayerFinish
2013-04-13 15:13:39 pptps: [pt0] LCP: state change Req-Sent --> Stopped
2013-04-13 15:13:39 pptps: [pt0] LCP: parameter negotiation failed
2013-04-13 15:13:37 pptps: ENDPOINTDISC [802.1] aa.bb.cc.dd.ee.ff
2013-04-13 15:13:37 pptps: MP SHORTSEQ
2013-04-13 15:13:37 pptps: MP MRRU 1600
2013-04-13 15:13:37 pptps: AUTHPROTO CHAP MSOFTv2
2013-04-13 15:13:37 pptps: MAGICNUM 3b3fcc20
2013-04-13 15:13:37 pptps: MRU 1500
2013-04-13 15:13:37 pptps: PROTOCOMP
2013-04-13 15:13:37 pptps: ACFCOMP
2013-04-13 15:13:37 pptps: [pt0] LCP: SendConfigReq #200
2013-04-13 15:13:35 pptps: ENDPOINTDISC [802.1] aa.bb.cc.dd.ee.ff
2013-04-13 15:13:35 pptps: MP SHORTSEQ
2013-04-13 15:13:35 pptps: MP MRRU 1600
2013-04-13 15:13:35 pptps: AUTHPROTO CHAP MSOFTv2
2013-04-13 15:13:35 pptps: MAGICNUM 3b3fcc20
2013-04-13 15:13:35 pptps: MRU 1500
2013-04-13 15:13:35 pptps: PROTOCOMP
2013-04-13 15:13:35 pptps: ACFCOMP
2013-04-13 15:13:35 pptps: [pt0] LCP: SendConfigReq #199
2013-04-13 15:13:33 pptps: ENDPOINTDISC [802.1] aa.bb.cc.dd.ee.ff
2013-04-13 15:13:33 pptps: MP SHORTSEQ
2013-04-13 15:13:33 pptps: MP MRRU 1600
2013-04-13 15:13:33 pptps: AUTHPROTO CHAP MSOFTv2
2013-04-13 15:13:33 pptps: MAGICNUM 3b3fcc20
2013-04-13 15:13:33 pptps: MRU 1500
2013-04-13 15:13:33 pptps: PROTOCOMP
2013-04-13 15:13:33 pptps: ACFCOMP
2013-04-13 15:13:33 pptps: [pt0] LCP: SendConfigReq #198
2013-04-13 15:13:31 pptps: ENDPOINTDISC [802.1] aa.bb.cc.dd.ee.ff
2013-04-13 15:13:31 pptps: MP SHORTSEQ
2013-04-13 15:13:31 pptps: MP MRRU 1600
2013-04-13 15:13:31 pptps: AUTHPROTO CHAP MSOFTv2
2013-04-13 15:13:31 pptps: MAGICNUM 3b3fcc20
2013-04-13 15:13:31 pptps: MRU 1500
2013-04-13 15:13:31 pptps: PROTOCOMP
2013-04-13 15:13:31 pptps: ACFCOMP
2013-04-13 15:13:31 pptps: [pt0] LCP: SendConfigReq #197
-
google -> "pptps: [pt0] LCP: parameter negotiation failed" leads me to many results
I repeat.. there is something (MTU?) on pfsense/m0n0wall side
I mean: if bypassing SME it works doesn't mean SME is the cause.. you said that pptp connection to other servers works..
and, again, you did not answer to all my questions.. how does the remote side connect?
-
I repeat.. there is something (MTU?) on pfsense/m0n0wall side
I doubt there is an MTU issue.
This looks to me like a problem with GRE path being only one way - we see LCP sent, but not received.
There is a lot of information about diagnosing such problems here:
http://pptpclient.sourceforge.net/howto-diagnosis.phtml#lcp_no_network_protocols
Doing packet capture (GRE and ICMP) on the passthrough SME server may reveal the cause of the problem.
-
With no changes whatsoever, it started working yesterday.
The following is the transcript of the pfSense v2.1 PPTP raw log:
pptps: [pt0] rec'd unexpected protocol IP
pptps: [pt0] IFACE: Up event
pptps: LAN.IP.PPTPServer91 -> DHCP.IP.TO.PPTPClient
pptps: [pt0] IPCP: LayerUp
pptps: [pt0] IPCP: state change Ack-Sent --> Opened
pptps: IPADDR LAN.IP.PPTPServer91
pptps: [pt0] IPCP: rec'd Configure Ack #52 (Ack-Sent)
pptps: IPADDR LAN.IP.PPTPServer91
pptps: [pt0] IPCP: SendConfigReq #52
pptps: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
pptps: [pt0] IPCP: rec'd Configure Reject #51 (Ack-Sent)
pptps: COMPPROTO VJCOMP, 16 comp. channels, no comp-cid
pptps: IPADDR LAN.IP.PPTPServer91
pptps: [pt0] IPCP: SendConfigReq #51
Is it possible that latency may have be an issue?
Or suddenly the ISP got selectively wise from their log alerts?
-
Is it possible that latency may have be an issue?
Yes. pptp works by client contacting server via TCP on port 1723, client and server negotiating to start the VPN, then client and server start sending GRE packets to each other. When there are NAT gateway/routers between client and server, GRE passthrough will sometimes only occur if outbound packets pass through before the first inbound packet arrives.
-
@CharlyBrady: Thanks for the analysis.
The troubleshooting link in this post too has been useful.