Hello,
After I upgraded my router I have problem with pptp. When user connected to pptp server and tries to mount nfs share server declined it. Server logs shows that request is being made by 192.168.88.1 but the remote ip is 192.168.87.x. I think i have some problem with routing. On client side subnet mask is 255.255.255.255. I am not sure if that is correct. Can you give me some ideas?
Thank you

Try /ip firewall service-port print where name=pptp. If the PORTS column is empty or contains any other port that 1723, do /ip firewall service-port set pptp ports=1723 and then try to connect again. Handling of GRE protocol has become more strict somewhere in 6.44.x and this is the consequence.

Mandatory warning: smoking kills, and PPTP is not secure.

Try /ip firewall service-port print where name=pptp. If the PORTS column is empty or contains any other port that 1723, do /ip firewall service-port set pptp ports=1723 and then try to connect again. Handling of GRE protocol has become more strict somewhere in 6.44.x and this is the consequence.

Mandatory warning: smoking kills, and PPTP is not secure.

I tried but still no changes.

/ip firewall service-port print
Flags: X - disabled, I - invalid
# NAME PORTS
0 ftp 21
1 tftp 69
2 irc 6667
3 h323
4 sip 5060
5061
5 I pptp 1723
6 udplite
7 dccp
8 sctp

If the PORTS column is empty or contains any other port that 1723, do /ip firewall service-port set pptp ports=1723

@sindy, since those are NAT helpers, do we actually need to set the pptp port there in case the router is not behind NAT ?

@sindy, since those are NAT helpers, do we actually need to set the pptp port there in case the router is not behind NAT ?

That's what I'm wondering myself. Strictly speaking it is not just a NAT helper but a firewall helper. The PPTP uses a control session at TCP/1723 and a GRE session to transport the actual payload. And GRE handling in firewall is what has been changed recently due to some vulnerability identified, and according to the information in the "6.44.x has been released" topic, switching the PPTP helper on was necessary to resolve the situation where the server side sends no payload to the client side until some payload packet comes from client side. In this situation, a tracked GRE "connection", whose existence is sufficient to accept incoming GRE packets from the client's IP thanks to the "accept established" rule in filter, does not get created in the firewall thanks to handling of an output GRE packet. By activating the helper, the incoming GRE packets are not treated as "new" in the absence of outgoing ones, but as "related" ones to the TCP/1723 ones already seen by the connection tracker, and this is the case even for local traffic, not just for forwarded one. The helper, which is a part of the conntrack module, is reading the control packets at TCP/1723, both locally generated/received ones and forwarded ones (i.e. where the Tik itself is neither a PPTP client nor a PPTP server), and according to their source and destination addresses it labels GRE packets with same or swapped source and destination as "related" so a rule "accept related" in filter lets them in (when the Tik itself is a PPTP client or server) or lets them be forwarded if Mikrotik stands between the client and the server.

But now, in 6.45.7, setting the port of the /ip firewall service-port row for pptp to 1723 makes status invalid be indicated for that row. So I have tested with 6.44.6 in production acting as PPTP client and the result was the same, but when the helper is just enabled but with the port value empty, the /interface pptp-client does come up; with the pptp helper completely disabled, it doesn't. The list of connection shows the GRE one related to PPTP as "expected":

# PROTOCOL
0 ESAC gre

(Expected here means that the packets handled by this tracked connections are labeled with connection-state "related").

So I had to quickly set up a PPTP client & server in the lab (on 6.45.7) to be able to provide a useful response, and it is even more strange. To make the tunnel come up, at the Tik acting as client it is enough (and necessary) that the pptp helper is enabled, but at the Tik acting as server, enabling the pptp helper is also necessary but not sufficient. On top of it, is also necesary to add protocol=!gre to the rule action=drop chain=input connection-state=invalid coming from the default configuration. So at the server side, the preceding rule action=accept chain=input connection-state=established,related,untracked from the default configuration does not accept the oncoming GRE packets even though they should be labeled as related.

So all in all, I don't get a clear view of what's actually happening under the hood after that CVE-related patch has been implemented. There are also other mysteries regarding connection tracker handling of GRE (outside the context of PPTP), for which I have already open a support ticket.

For the OP: remove the port 1723 from the pptp helper setting, but modify the "drop invalid" rule in the input chain as decribed a few lines above.

I tried what you suggested but still no result. I think pptp is routed somehow but i don't know how to make rule to nat it with internal network.

Maybe i have simply misunderstood your OP because it was too brief, and you may have not read my last one carefully enough to pick the part relevant for your actual topology from it

So can you clarify whether your PPTP server is the Mikrotik itself, or whether the Mikrotik stands between the server and its clients? Because if it is the latter case, you probably have to modify the action=drop connection-state=invalid in chain=forward given that enabling the pptp helper without specifying a port is not sufficient.

Or maybe the PPTP connection is actually successfully established between the client and the Mikrotik acting as a server (/interface pptp-server print shows a dynamically created interface), but the payload traffic coming via the PPTP tunnel is not handled properly?

In another words, too many unclear points, please provide more details.

My PPTP serser is Mikrotik itself. PPTP connection is actually successfully established between the client and the Mikrotik acting as a server. Here is my configuration:

/interface bridge
add admin-mac=D4:CA:6D:BA:67:FD arp=proxy-arp auto-mac=no fast-forward=no \
mtu=1500 name=bridge-local
/interface ethernet
set [ find default-name=ether1 ] mac-address=64:66:B3:77:0F:4B name=\
ether1-gateway speed=1Gbps
set [ find default-name=ether2 ] name=ether2-master-local speed=1Gbps
set [ find default-name=ether3 ] master-port=ether2-master-local name=\
ether3-slave-local speed=1Gbps
set [ find default-name=ether4 ] master-port=ether2-master-local name=\
ether4-slave-local speed=1Gbps
set [ find default-name=ether5 ] master-port=ether2-master-local name=\
ether5-slave-local speed=1Gbps
/interface pptp-server
add name="PPTP VPN" user=""
/ip pool
add name=dhcp ranges=192.168.88.10-192.168.88.240
add name=PPTPDHCP ranges=192.168.87.10-192.168.87.240
add name=L2TPDHCP ranges=192.168.89.10-192.168.89.240
/ip dhcp-server
add address-pool=dhcp authoritative=after-2sec-delay disabled=no interface=\
bridge-local lease-time=3d name=default
/ppp profile
add local-address=192.168.87.250 name=PPTPprofile remote-address=PPTPDHCP \
use-encryption=yes
add change-tcp-mss=yes local-address=192.168.89.250 name=L2TPprofile \
remote-address=L2TPDHCP
add local-address=192.168.85.250 name=PPTPnezi remote-address=192.168.85.101
add local-address=192.168.85.250 name=PPTP4i4o remote-address=192.168.85.102

/interface bridge port
add bridge=bridge-local interface=ether2-master-local
add bridge=bridge-local interface=wlan1

/interface pptp-server server
set authentication=pap,chap,mschap1,mschap2 default-profile=PPTPprofile \
enabled=yes max-mru=1460 max-mtu=1460

/ip firewall filter
add action=accept chain=input comment="default configuration" protocol=icmp
add action=accept chain=input comment="default configuration" \
connection-state=established
add action=accept chain=input comment="default configuration" \
connection-state=related packet-mark=""
add action=drop chain=input comment="default configuration" in-interface=\
ether1-gateway
add action=accept chain=forward comment="default configuration" \
connection-state=established
add action=accept chain=forward comment="default configuration" \
connection-state=related
add action=drop chain=forward comment="default configuration" \
connection-state=invalid
add action=accept chain=forward comment="port forwarding try" disabled=yes \
dst-port=80 protocol=tcp
/ip firewall nat
add action=masquerade chain=srcnat comment="default configuration" \
out-interface=*FFFFFFFF
add action=masquerade chain=srcnat out-interface=pppoe-out1
add action=dst-nat chain=dstnat comment="Trying port forwarding" dst-port=80 \
in-interface=pppoe-out1 protocol=tcp to-addresses=192.168.88.202 \
to-ports=80
add action=src-nat chain=srcnat dst-port=80 out-interface=pppoe-out1 \
protocol=tcp src-address=192.168.88.101 to-addresses=84.22.27.96 \
to-ports=80
add action=dst-nat chain=dstnat comment="ssh forwarding" dst-port=23000 \
in-interface=pppoe-out1 protocol=tcp to-addresses=192.168.88.202 \
to-ports=22

/ppp secret
add name=pptpuser password=XXXXXXX profile=PPTPprofile remote-address=\
192.168.87.105 service=pptp

Please show me the output of /ip firewall nat print (and maybe replace the public address by i.i.i.i or so before posting and edit it in your previous post).

After doing the print above, disable the first action=src-nat rule, with out-interface=*FFFFFFFF, and try the NFS connection again.

/ip firewall nat print
Flags: X - disabled, I - invalid, D - dynamic
0
chain=srcnat action=masquerade out-interface=ether1-gateway log=no
log-prefix=""

1 chain=srcnat action=masquerade out-interface=pppoe-out1 log-prefix=""

2 ;;; Trying port forwarding
chain=dstnat action=dst-nat to-addresses=192.168.88.202 to-ports=80
protocol=tcp in-interface=pppoe-out1 dst-port=80 log-prefix=""

3 chain=srcnat action=src-nat to-addresses=i.i.i.i to-ports=80
protocol=tcp src-address=192.168.88.101 out-interface=pppoe-out1
dst-port=80 log-prefix=""

4 ;;; ssh forwarding
chain=dstnat action=dst-nat to-addresses=192.168.88.202 to-ports=22
protocol=tcp in-interface=pppoe-out1 dst-port=23000 log=no log-prefix=""

Disabling the first action=src-nat rule, with out-interface=*FFFFFFFF actually solved the problem but I don't understand why. This is default rule.

IIRC, an interface pointing to *FFFF points to an interface that does not exist anymore, i.e. deleted

talanfree says:

Disabling the first action=src-nat rule, with out-interface=*FFFFFFFF actually solved the problem but I don't understand why. This is default rule.

CZFan says:

IIRC, an interface pointing to *FFFF points to an interface that does not exist anymore, i.e. deleted

@sindy says:
That's exactly the reason why I wanted to see the output of the print before the rule was disabled. Whereas *23f and similar hex numbers prefixed with a star are really links to objects which have been removed from the configuration in the meantime, *0 and *FFFFFFFF have a special meaning in some parts of the configuration, which is "the first element in the list" and "the last element in the list" (except that you don't know which one is actually the first one and which one is last).

So I wanted to have this confirmed in this case, and indeed the print has revealed that the *FFFFFFFF from the configuration data has been translated to a normal interface ID whose name is, in this case, ether1-gateway.

I wasn't expecting it to be ether1-gateway, I was actually expecting it to be bridge-local or no interface at all, but that's another thing.

Not knowing your network topology, and since you posted only the part of configuration which you deemed relevant, I can only give generic explanations.

If you really connect to internet using /interface pppoe client, then its carrying L2 interface in typical cases doesn't have any IP configuration attached to it, so it is non-existent for the firewall. It is not a law, though, you can use the same (V)LAN to carry PPPoE traffic and one or more IP subnets simultaneously.

In any case, the rule I've asked you to disable was causing packets coming from the PPTP client to be src-nated to Mikrotik's own address attached to the L3 interface through which they were forwarded to the NFS server. By disabling the rule, this stopped happening and the NFS server can see the actual PPTP-assigned address of the client.

Whether disabling the rule has fixed the original issue but broken something else instead is a separate question, it depends on whether your L3 uplink to internet is pppoe-out1 or really ether1-gateway. So if it did, you have to replace it with a more selective one.

And how comes that a default rule ends up with *FFFFFFFF as an interface ID is another separate question which I cannot answer.

Thank you for your help. I'll see if everything else is working.

Hello guys !
Problem with how to do PPTP over NAT is still actual and I can not solve it use hints in this topic or any info in web.
So question - does someone knows how to use workable service PPTP VPN under the NAT.
My router is CCR1036 r2 with 6.46.6 RouterOS.
At old CCR1016 with 6.44.6 and same config as on new - was no problems with PPTP.
Also PPTP on "whyte" IPs without NAT works well through CCR1036 .
And here what I can see at log during bad connection with refuse VPN:
First try-
jul/02 00:10:35 firewall,info VPN-TEST forward: in:vlanLOCAL out:vlanBGPVLAN, src-mac 00************, proto TCP (SYN), localip:50959->VPNserverIP:1723, len 52
Second try-
jul/02 00:12:55 firewall,info VPN-TEST forward: in:vlanLOCAL out:vlanBGPVLAN, src-mac 00*************, proto TCP (SYN), localip:50978->VPNserverIP:1723, len 52

First of all, are you talking about NAT at client side or a NAT at server side? Post your anonymized config from the 1036 following the hint in my automatic signature just below.

First of all, are you talking about NAT at client side or a NAT at server side? Post your anonymized config from the 1036 following the hint in my automatic signature just below.

BGP -> CCR1036 with NAT -> client that want to work with PPTP without router or with. Result - VPN does not work.
I sent config via PM

Thank u for reply !

Problem solved
Used info from this topic viewtopic.php?t=49621
Need to apply couple of times /ip firewall service-port set pptp ports="" before text will stop to be red

Hi,
I am new writing in mikrotik forum, but I need your help.
I have a CCR1072 (version 6.45.8 (long-term)) where I do a firewall/mangle/QoS/NAT over all my aggregated clients.
Before, I have a CCR1036 and I think that the pptp forward traffic across the CCR1036 was running, but for my surprise, in CCR1072 isn't working.
I tried to configure the pptp services but it didn't work.
Can you help me?
Thank you in advanced.
Regards.
David.

Hello, I have a problem similar to his, but in my case it is that I cannot configure the IP cloud because my device has a private IP that is given to me by a mobile phone server, so when I try to activate it to be able to connect in a way remote, in the cloud sale it tells me to post nat and well, it is obvious that nat is from the internet distributor that this case is a mobile phone provider, is to say a sim card, what can I do to enter remotely in this case?
My device is a LtAP LTE, with three slots for sim cards.
I await response, thanks, regards.