Koozali.org: home of the SME Server
Obsolete Releases => SME Server 7.x => Topic started by: guest22 on March 21, 2009, 10:28:05 PM
-
Hi,
I'm trying to connect to a fresh SME server 7.4. It's behind a firewall that I do not control. Is there a specific port or ports that must be opened on that firewall to establish a correct VPN connection please? See below the 7.4 that I am trying to connect to from a windows xp machine.
Thanks
guest
----------- (removed private details)
pptpd[2320]: CTRL: Client xx.xx.xx.xx control connection started
Mar 21 22:21:58 pptpd[2320]: CTRL: Starting call (launching pppd, opening GRE)
Mar 21 22:21:58 pppd[2321]: Plugin radius.so loaded.
Mar 21 22:21:58 pppd[2321]: RADIUS plugin initialized.
Mar 21 22:21:58 pppd[2321]: pppd 2.4.4 started by root, uid 0
Mar 21 22:21:58 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
Mar 21 22:21:58 pppd[2321]: Using interface ppp0
Mar 21 22:21:58 pppd[2321]: Connect: ppp0 <--> /dev/pts/0
Mar 21 22:22:28 pppd[2321]: LCP: timeout sending Config-Requests
Mar 21 22:22:35 pptpd[2320]: CTRL: Reaping child PPP[2321]
Mar 21 22:22:35 pppd[2321]: Modem hangup
Mar 21 22:22:35 pppd[2321]: Connection terminated.
Mar 21 22:22:35 kernel: divert: no divert_blk to free, ppp0 not ethernet
Mar 21 22:22:35 pppd[2321]: Exit.
Mar 21 22:22:35 pptpd[2320]: CTRL: Client xx.xx.xx.xx control connection finished
------------
-
The firewall needs to be able to pass PPTP/GRE Traffic. Is it an appliance firewall (SONIC) or something like IPCop or Smoothwall ?
I have beaten this one also by disabling LCP on the XP machine.
Also found that when a connection fails, it can take several minutes for SME to clear the connection and permit a new connection. Without that wait, any tweaks / changes are futile. Always a bad outcome.
-
I have beaten this one also by disabling LCP on the XP machine.
AIUI, LCP is required for PPTP to work. Are you quite sure you disabled LCP? If so how, and what was the result.
-
The firewall needs to be able to pass PPTP/GRE Traffic.
If the fireweall doesn't support forwarding GRE traffic specifically, then you can put the server in the DMZ, so that all traffic is forwarded to SME. That will almost certainly work.
-
I disabled LCP it in the properties of the XP network connection for the vpn
-
Firewall mentioned above is a Cisco PIX
Tried the 'disable LCP in VPN connection', did not work, same result.
Thanks,
guest
-
HF - Sorry. At the end of my road. No more suggestions even though that block from the logs is too familiar to me !
-
HF - Sorry. At the end of my road. No more suggestions even though that block from the logs is too familiar to me !
That line in the logs just indicates that GRE traffic is not arriving at the server from the client.
-
Thanks,
here are the current PIX rules for the SME Server 7.4 behind it:
----------------
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx object-group DMZ-firewall-tcp
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq 1022 (hitcnt=123)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq 465 (hitcnt=0)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq 995 (hitcnt=0)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq smtp (hitcnt=173)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq 993 (hitcnt=0)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq ident (hitcnt=0)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq www (hitcnt=10930)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq ssh (hitcnt=126)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq pptp (hitcnt=17)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq 5061 (hitcnt=0)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq sip (hitcnt=0)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq https (hitcnt=79)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq ftp-data (hitcnt=1)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq ftp (hitcnt=2375)
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq ctiqbe (hitcnt=0)
access-list acl_outside line 22 extended permit udp any host xx.xx.xx.xx object-group DMZ-firewall-UDP
access-list acl_outside line 24 extended permit gre any host xx.xx.xx.xx (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any object-group DMZ-firewall-tcp
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq 1022 (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq 465 (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq 995 (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq smtp (hitcnt=10)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq 993 (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq ident (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq www (hitcnt=1816)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq ssh (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq pptp (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq 5061 (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq sip (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq https (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq ftp-data (hitcnt=0)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq ftp (hitcnt=138)
access-list DMZlan_access_in line 3 extended permit tcp host xx.xx.xx.xx any eq ctiqbe (hitcnt=0)
access-list DMZlan_access_in line 5 extended permit udp host xx.xx.xx.xx any object-group DMZ-firewall-UDP
access-list DMZlan_access_in line 6 extended permit tcp host xx.xx.xx.xx any eq domain (hitcnt=0)
access-list DMZlan_access_in line 7 extended permit udp host xx.xx.xx.xx any eq domain (hitcnt=28767)
access-list DMZlan_access_in line 8 extended permit gre host xx.xx.xx.xx any (hitcnt=7)
--------------------
-
I don't see 1194 udp forwarded to the server?
BTW why are you deploying a SME VPN Server within a perimeter firewall??
Some special reason for negating quality network security practices and deployment?
Certainly hope it's not a business network.
-
The 7.4 box has been given a spot beyond my control. Reason to VPN to it is to access the server-manager.
UDP 1194 is used by OpenVPN isn't it? The 7.4 box is not a OpenVPN box. VPN access required is the default SME 7.4 VPN access method.
Thanks,
guest
-
access-list acl_outside line 24 extended permit gre any host xx.xx.xx.xx (hitcnt=0)
maybe there's something in front of your pix (wan side) that block GRE.. how is that network connected?
Ciao
Stefano
-
Home networks -> ISP1 -> Public internet -> ISP2 -> SME 7.4
Both ISP2 and SME 7.4 are on the same premisses. (ISP2 hosts the 7.4 box)
Thanks,
guest
ps. I can contact ISP2 and trace whatever is traceable on the non-public networks. Any pointers please?
-
ok..
I'm not a cisco fan/user, so.. is the pix that keep you connected? I mean, is it a router? is there something in front of it?
did you try to connect to the same SME from another wan connection (different isp)?
Ciao
Stefano
-
The PIX firewall apparently provides controlled/secure access to a DMZ at ISP2, from that DMZ traffic is being forwarded to the internal 7.4 box. There is nothing else in front of it.
I will try connecting through UMTS (Cell phone) later this (yours and mine ;-) ) evening.
Thanks,
guest
-
Ok, tried a different route/ISP (UMTS)
Here are the results as seen on the SME 7.4 box:
------ (private details removed)
Mar 22 19:43:26 pptpd[23638]: CTRL: Client xx.xx.xx.xx control connection started
Mar 22 19:43:27 pptpd[23638]: CTRL: Starting call (launching pppd, opening GRE)
Mar 22 19:43:27 pppd[23639]: Plugin radius.so loaded.
Mar 22 19:43:27 pppd[23639]: RADIUS plugin initialized.
Mar 22 19:43:27 pppd[23639]: pppd 2.4.4 started by root, uid 0
Mar 22 19:43:27 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
Mar 22 19:43:27 pppd[23639]: Using interface ppp0
Mar 22 19:43:27 pppd[23639]: Connect: ppp0 <--> /dev/pts/1
Mar 22 19:43:57 pppd[23639]: LCP: timeout sending Config-Requests
Mar 22 19:44:03 pptpd[23638]: CTRL: Reaping child PPP[23639]
Mar 22 19:44:03 pppd[23639]: Modem hangup
Mar 22 19:44:03 pppd[23639]: Connection terminated.
Mar 22 19:44:03 kernel: divert: no divert_blk to free, ppp0 not ethernet
Mar 22 19:44:03 pppd[23639]: Exit.
Mar 22 19:44:03 pptpd[23638]: CTRL: Client xx.xx.xx.xx control connection finished
-----
Thanks,
guest
-
Reason to VPN to it is to access the server-manager.
Sorry, didn't realize you were using SME default PPTP.
Was the PIX configured for PPTP??
Not sure if this is your Cisco PIX, you weren't specific.
Cisco Pix 500 (http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094a5a.shtml)
hth
-
What network card is in the SME.
Mar 22 19:43:27 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
That looks like a nic driver issue or an SME bug.
-
I disabled LCP it in the properties of the XP network connection for the vpn
Really? Are you sure you didn't disable 'LCP extensions'? LCP is necessary:
http://www.ietf.org/rfc/rfc1548.txt
Link Control Protocol
In order to be sufficiently versatile to be portable to a wide
variety of environments, PPP provides a Link Control Protocol
(LCP). The LCP is used to automatically agree upon the
encapsulation format options, handle varying limits on sizes of
packets, authenticate the identity of its peer on the link,
determine when a link is functioning properly and when it is
defunct, detect a looped-back link and other common
misconfiguration errors, and terminate the link.
-
Was the PIX configured for PPTP??
Sorry, I don't know. But I can ask staff at ISP2 to change whatever I suggest.
Thanks,
guest
-
What network card is in the SME.
lspci:
02:00.1 PIC: Intel Corporation 6700/6702PXH I/OxAPIC Interrupt Controller A (rev 09)
03:02.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 6c)
lsmod:
e1000 120273 0
3c59x 41469 0
show config:
EthernetAssign=normal
EthernetDriver1=3c59x
EthernetDriver2=e1000
Thanks,
guest
-
What network card is in the SME.
Mar 22 19:43:27 kernel: divert: not allocating divert_blk for non-ethernet device ppp0
That looks like a nic driver issue or an SME bug.
Neither. It's harmless log noise from the diverter kernel module (an attempt was made to remove it in 2005, but wasn't followed through):
http://oss.sgi.com/archives/netdev/2005-01/msg00586.html
-
When I did some Cisco training a few years back I was told that the PIX devices acted rather differently to standard routers in a variety of situations. So unfortunately there may be something PIX-specific else going on that is preventing the VPN connection from working.
-
According to:
http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_configuration_example09186a0080094a5a.shtml#maintask1
section: PPTP with the Client Outside and the Server Inside
TCP port 1723 needs to added to the rules. Reading this, I vaguely remember this requirement from earlier discussion on the forums. I have requested ISP2 to perform the change.
Searching the forums on '1723' results in a massive amount of posts....
Will post the result.
Thanks,
guest
-
as far as I can see, you have it already
access-list acl_outside line 21 extended permit tcp any host xx.xx.xx.xx eq pptp (hitcnt=17)
Ciao
Stefano
-
Neither. It's harmless log noise from the diverter kernel module (an attempt was made to remove it in 2005, but wasn't followed through):
http://oss.sgi.com/archives/netdev/2005-01/msg00586.html
Yea I researched that and found it and was going to post it, then the couch got me.