SYSTEM WARNING: 'date_default_timezone_get(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone.' in '/usr/share/mantis/www/core.php' line 264

0002991: PPTP VPN Port Forwarding is not working - MantisBT Endian Bugtracker
Endian Issue Tracker





Please see now our new Bugtracker system: JIRA








View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0002991Endian FirewallFirewall (iptables)public2010-06-09 17:072010-10-05 10:20
ReporterKiekeboe100 
Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
StatusclosedResolutionno change required 
PlatformOSOS Version
Product Version2.4 
Target VersionFixed in Version 
Summary0002991: PPTP VPN Port Forwarding is not working
DescriptionHi,

I'm trying to set up PPTP VPN Forwarding to a PPTP Server in my network.

I've set up forwarding TCP 1723 (RED) to 192.168.123.2 (GREEN)
And GRE/47 (RED) to 192.168.123.2 (GREEN)

When I run some tests with the Microsoft Support Tools (pptpclnt.exe and pptpsrv.exe) it seems that PPTP is allowed through, but GRE isn't forwarded.

I also tested by rejecting and logging GRE packages, but I can't find anything about this in the log files.

Kind Regards,
Stijn
TagsNo tags attached.
Attached Filesjpg file icon VPN 1 of 3.jpg [^] (16,546 bytes) 2010-09-21 13:53


jpg file icon VPN 2 of 3.jpg [^] (159,307 bytes) 2010-09-21 13:53


jpg file icon VPN 3 of 3.jpg [^] (161,311 bytes) 2010-09-21 13:53

- Relationships
has duplicate 0002253acknowledged Firewall not passing GRE packets 

-  Notes
(0004486)
baldy (reporter)
2010-06-11 08:32

I can confirm the issue.

just tested on an upgraded EFW 2.4 community.

Ras error code is 806, description for the error is:
 
A connection between your computer and the VPN server has been started, but the VPN connection cannot be completed. The most common cause for this is that at least one Internet device (for example, a firewall or a router) between your computer and the VPN server is not configured to allow Generic Routing Encapsulation (GRE) protocol packets. If the problem persists, contact your network administrator or Internet service provider.

Server side logs similar errors (eventid 20209):

A connection between the VPN server and the VPN client: %1 has been established but the VPN connection cannot be completed. The most common cause for this is that a firewall or router between the VPN server and the VPN client is not configured to allow Generic Routing Encapsulation (GRE) packets (protocol 47).

Firewall setup:

Ports forwarded are TCP 1723 (tested with and without IPS) and GRE (tested with no port number, port number 0 and port number 47, with and without IPS and with and without NAT.

Regards,

Klaas-Jan
(0004488)
baldy (reporter)
2010-06-11 08:47

Looks like an iptables fault.

Used iptables --list | grep gre

Not working 2.4

RETURN gre -- anywhere 192.168.0.1

Working 2.1

ACCEPT gre -- anywhere 192.168.1.1

Difference is the RETURN, which should be ACCEPT
(0004492)
Kiekeboe100 (reporter)
2010-06-11 12:13

If i print a list of iptables I can see the following rules:

NFLOG tcp -- anywhere 192.168.123.2 tcp dpt:pptp nflog-prefix "PORTFWACCESS:ALLOW:1"
ALLOW tcp -- anywhere 192.168.123.2 tcp dpt:pptp
NFLOG gre -- anywhere 192.168.123.2 nflog-prefix "PORTFWACCESS:ALLOW:2"
ALLOW gre -- anywhere 192.168.123.2

Both rules (PPTP and GRE) seem to be set up the same way.
(0004787)
peter-endian (administrator)
2010-09-21 13:14

after a first sight i must say that the created iptables rules on a 2.4 are correct. i can't reproduce the rule with the RETURN.

can you please attach a screenshot with your configuration. probably there's only a misconfiguration, since RETURN will be generated only in certain cases.
(0004790)
baldy (reporter)
2010-09-21 13:55

Peter,

I have uploaded the screenshots.
Configuration in 2.2 (which worked) was exactly the same.
(0004821)
peter-endian (administrator)
2010-09-23 10:28

thank you. it is all correct
hmm.. can you please post also:

iptables -vnL PORTFWACCESS
iptables -t nat -vnL PORTFW

and then, can you try to

setdnat.py --force

and try again?
(0004857)
baldy (reporter)
2010-09-23 19:58

root@efw-1245489373:~ # iptables -vnL PORTFWACCESS
Chain PORTFWACCESS (1 references)
 pkts bytes target prot opt in out source destination

    1 48 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:80
   42 2360 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:443
    3 156 ACCEPT tcp -- * * 77.250.0.0/15 192.168.8.1
        tcp dpt:3389
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:1723
 1585 82472 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.10
        tcp dpt:81
    0 0 ALLOW 47 -- * * 0.0.0.0/0 192.168.8.1

    0 0 ACCEPT tcp -- * * 77.250.0.0/16 192.168.8.1
        tcp dpt:3389
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:80
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:4125
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:443
    0 0 ACCEPT 47 -- * * 0.0.0.0/0 192.168.8.1

    0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.1
        tcp dpt:1723
    0 0 ACCEPT tcp -- * * 0.0.0.0/0 192.168.8.3
        tcp dpt:51413
root@efw-1245489373:~ #
(0004858)
baldy (reporter)
2010-09-23 20:00

root@efw-1245489373:~ # iptables -t nat -vnL PORTFW
Chain PORTFW (2 references)
 pkts bytes target prot opt in out source destination

    1 48 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:80 to:192.168.8.1:80
   42 2360 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:443 to:192.168.8.1:443
    3 156 DNAT tcp -- * * 77.250.0.0/15 83.161.15.8
        tcp dpt:3389 to:192.168.8.1:3389
    0 0 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:1723 to:192.168.8.1:1723
 1586 82524 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:81 to:192.168.8.10:81
    0 0 DNAT 47 -- * * 0.0.0.0/0 83.161.15.8
        to:192.168.8.1
    0 0 DNAT tcp -- * * 77.250.0.0/16 83.161.15.8
        tcp dpt:3389 to:192.168.8.1:3389
    0 0 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:80 to:192.168.8.1:80
    0 0 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:4125 to:192.168.8.1:4125
    0 0 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:443 to:192.168.8.1:443
    0 0 DNAT 47 -- * * 0.0.0.0/0 83.161.15.8
        to:192.168.8.1
    0 0 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:1723 to:192.168.8.1:1723
    0 0 DNAT tcp -- * * 0.0.0.0/0 83.161.15.8
        tcp dpt:51413 to:192.168.8.3:51413
root@efw-1245489373:~ #
(0004859)
baldy (reporter)
2010-09-23 20:04

Hi Peter,

After setdnat.py --force things started working again.

If you need more info let me know.

Regards,

Klaas-Jan
(0004860)
baldy (reporter)
2010-09-23 20:06

Also iptables have changed :

root@efw-1245489373:~ # iptables --list | grep gre
ACCEPT gre -- anywhere 192.168.8.1
ACCEPT gre -- anywhere 192.168.8.1
root@efw-1245489373:~ #

No more RETURN
(0004914)
peter-endian (administrator)
2010-10-05 10:20

great. so this in fact is a problem of the firewall script.
for now we need to leave this as it is since, restarting the script can be a workaround however

until we refactor the firewall script in order to eliminate this case where rules are not consistent with the configuration.

i close this ticket now, since it should work as it is, please reopen if there is still an issue with PPTP itself (not with the portfw firewall script)

- Issue History
Date Modified Username Field Change
2010-06-09 17:07 Kiekeboe100 New Issue
2010-06-11 08:32 baldy Note Added: 0004486
2010-06-11 08:47 baldy Note Added: 0004488
2010-06-11 12:13 Kiekeboe100 Note Added: 0004492
2010-09-21 13:14 peter-endian Note Added: 0004787
2010-09-21 13:14 peter-endian Status new => feedback
2010-09-21 13:53 baldy File Added: VPN 1 of 3.jpg
2010-09-21 13:53 baldy File Added: VPN 2 of 3.jpg
2010-09-21 13:53 baldy File Added: VPN 3 of 3.jpg
2010-09-21 13:55 baldy Note Added: 0004790
2010-09-23 10:28 peter-endian Note Added: 0004821
2010-09-23 15:30 peter-endian Relationship added has duplicate 0002253
2010-09-23 19:58 baldy Note Added: 0004857
2010-09-23 20:00 baldy Note Added: 0004858
2010-09-23 20:04 baldy Note Added: 0004859
2010-09-23 20:06 baldy Note Added: 0004860
2010-10-05 10:20 peter-endian Note Added: 0004914
2010-10-05 10:20 peter-endian Status feedback => closed
2010-10-05 10:20 peter-endian Resolution open => no change required

Copyright © 2005-2008 Endian, SRL. All rights reserved.


Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker