I have seen countless articles and howto's on doing a PPTP Server from the MikroTik and connecting a Windows XP or Windows 7 client but with all the different options I still can't connect. I usually get the Error 800.

I'm basically connecting a Windows 7 Client over the Internet and into the Router. So I use the routers PUBLIC IP on the client side and in the profile as you see for local address I have the routers internal IP of 192.168.1.1. The local network to the windows 7 client has an ip scheme of 192.168.10.0/24.


Here is what my config looks like. Please advise and thanks

I'm on version 5.6













Windows 7 Setup

There is an excellent article at Greg Sowell's site http://gregsowell.com/?p=680

You might also like to turn on logging for PPTP /system logging add action=memory disabled=no prefix="" topics=pptp

This should help in debugging.

Are you using L2TP over IPSEC or PPTP on the Windows PC ? Double check the security properties of the VPN Connection under Windows

There is an excellent article at Greg Sowell's site http://gregsowell.com/?p=680

You might also like to turn on logging for PPTP /system logging add action=memory disabled=no prefix="" topics=pptp

This should help in debugging.

Are you using L2TP over IPSEC or PPTP on the Windows PC ? Double check the security properties of the VPN Connection under Windows

I'm using PPTP specific setting on the windows 7 pro client instead of automatic. can there be a licensing issue here? I'm on level 4. It gives this error immediately also upon hitting connect on the windows 7 client. here is my issue after doing exactly what that article said. Also I enabled the logging for pptp and I don't see any entries in the routers log file







I felt like I should add my ip setup as well. listed here. there is a voip subnet and a data subnet

http://wiki.mikrotik.com/wiki/Manual:Li ... nse_Levels

Level 4 allows 200 PPTP clients so I do not think that is the issue.

What does the Mikrotik Log show ?

http://wiki.mikrotik.com/wiki/Manual:Li ... nse_Levels

Level 4 allows 200 PPTP clients so I do not think that is the issue.

What does the Mikrotik Log show ?

Be sure to add PPTP logging as per my original post and try again then post the log

If you have done that already then no PPTP packets are hitting your router and the problem is elsewhere - perhaps disable ANY firewall Input rules and try again ?

This also from MS Technet:

Microsoft error codes doesn't really tell you what's wrong. A error code 807 typically is either the client or the server is behind a NAT device and does not pass through GRE protocol 47. If GRE protocol 47 isn't pass through the NAT device you'll get 807. you'll also get 807 if port 1723 isn't forwarded from the NAT device to the VPN server if the server is behind a NAT device. VPN servers usually have packet filters which restrict inbound connection to only PPTP or L2TP.

=================

Perhaps an IP Firewall Rule on the Input chain to log everything (placed at the top) to be sure the packets are arriving at the Mikrotik router ?

thanks for your help. does this look like i've enabled pptp-info logging

Sure does, and ppp, pppoe etc.

I do not see any actual PPTP entries in the log though.

We need to confirm the PPTP packets are arriving at the Mikrotik as the issue may be at the client side ?

Is the client a fixed IP ? If so add an Input rule with the necessary source address and action of LOG and a prefix of VPN (or W7VPN etc to identify the packets).

This should show the traffic from the host hitting the Mikrotik.

Also disable any logging that is not pertinent to what we need such as PPP and PPPoE


If that does not show anythinmg useful the perhaps disable all logging except PPTP then start a Packet Capture on ether1 then do the connection attempt and stop it and look at the packets to make sure you are getting through to the Mikrotik.

In winbox use Tool.Packet Sniffer for this.

We need to see that traffic arriving at the router

Sure does, and ppp, pppoe etc.

I do not see any actual PPTP entries in the log though.

We need to confirm the PPTP packets are arriving at the Mikrotik as the issue may be at the client side ?

Is the client a fixed IP ? If so add an Input rule with the necessary source address and action of LOG and a prefix of VPN (or W7VPN etc to identify the packets).

This should show the traffic from the host hitting the Mikrotik.

Also disable any logging that is not pertinent to what we need such as PPP and PPPoE


If that does not show anythinmg useful the perhaps disable all logging except PPTP then start a Packet Capture on ether1 then do the connection attempt and stop it and look at the packets to make sure you are getting through to the Mikrotik.

In winbox use Tool.Packet Sniffer for this.

We need to see that traffic arriving at the router

the strange thing is if I do a ping from the client I see his public static IP hitting the microtek under an ICMP packet. If I do a connection from the vpn client when it's on automatic it trys to connect to port 500 on the microtek and eventually fails. when I actually set the client to PPTP tunneling it fails right away and there are no logs on the microtek. firewall is disabled on the client. no av software. I've tried this same procedure from a completely different network with a different PC/LAN subnet and had the same result as I just described. and this happens on xp and windows 7.

Another update. If the sniffer is on and I connect on my 192.168.0.0/24 network it will show entries for 1723 as the destination port. I will have to keep hitting redial in order for them to show up but they do show up. on the network that has subnet 192.168.10.0/24 the destination port 1723 packets never show up during the sniffing. this is when filtered to look at all traffic destined for the ether1 interface.

In Winbox, go into your firewall rules and place three rules right at the top.
One to allow all input
One to allow all output
One to allow all forwards.

Then you can "enable" or "disable" them for your test.

Enable them and try the PPTP connect.
If it works, then you have a firewall problem.
If they don't, you have a problem elsewhere.

---
Once you're sure it's not a firewall problem, then we can look farther up the OSI layers to see what's going on. But, IMO, it's often something like this that causes the problem.

When it's so easy to test for, it seems crazy not to spend the 3 minutes or so to create the rules and try it.
[In fact, often when something works differently than I expect, I'll try this myself. It's a terribly easy way to determine if there's some rule you hadn't considered that is borking you over. Once you know that, you can disable the "allow" rules and go searching.]

-Greg

In Winbox, go into your firewall rules and place three rules right at the top.
One to allow all input
One to allow all output
One to allow all forwards.

Then you can "enable" or "disable" them for your test.

Enable them and try the PPTP connect.
If it works, then you have a firewall problem.
If they don't, you have a problem elsewhere.

---
Once you're sure it's not a firewall problem, then we can look farther up the OSI layers to see what's going on. But, IMO, it's often something like this that causes the problem.

When it's so easy to test for, it seems crazy not to spend the 3 minutes or so to create the rules and try it.
[In fact, often when something works differently than I expect, I'll try this myself. It's a terribly easy way to determine if there's some rule you hadn't considered that is borking you over. Once you know that, you can disable the "allow" rules and go searching.]

-Greg

I enabled all of them but still can't get in. what are the settings I should have on my client that are correct so I at least know that each end is setup the correct way? it's crazy how fast it ends the session as well, it's instant there isn't even like a delay while it tries.

After further testing from within the same network as the microtik I was able to connect a client just fine. So I know the pptp server is setup correctly. what other WAN requirements are needed for this to work? there must be something missing on the microtik.

thanks

After further testing from within the same network as the microtik I was able to connect a client just fine.

Does this mean that you essentially put the client hanging off one of the WAN ports of the MicroTik - just via an ethernet cable. Gave both appropriate IP addresses and it worked. Correct?

If so, there's nothing wrong with either setup - client or server.

1) If you didn't plug it into the same WAN port you'd use to connect to your ISP, then you likely have a misconfiguration of the MikroTik
2) If you did, then there's something wrong with your ISP, or some filtering that is occurring in the middle somewhere.
- If you're using a Comcast modem, they have "filtering" options that will bork IPSec and PPTP, IIRC. Turn those off.
- If you have DSL, is there a DSL router in the middle doing NAT?

You didn't show the IP address of the WAN interface [which I understand] but without it, I'm not sure if there's NAT going on in the middle of your connection. [Outside the MTK]

I haven't reviewed your post super carefully, but if you've followed the Wiki, or Sowell's walk-through - I'm pretty sure it's right and you need to start looking outside the MTK/Windows client for problems. [I've setup many using the Wiki setup, and I know it works.]

Oh, and don't use CHAP1 it's very insecure, IMO. MS-CHAP2 is much better.

-Greg

After further testing from within the same network as the microtik I was able to connect a client just fine.

Does this mean that you essentially put the client hanging off one of the WAN ports of the MicroTik - just via an ethernet cable. Gave both appropriate IP addresses and it worked. Correct?

If so, there's nothing wrong with either setup - client or server.

1) If you didn't plug it into the same WAN port you'd use to connect to your ISP, then you likely have a misconfiguration of the MikroTik
2) If you did, then there's something wrong with your ISP, or some filtering that is occurring in the middle somewhere.
- If you're using a Comcast modem, they have "filtering" options that will bork IPSec and PPTP, IIRC. Turn those off.
- If you have DSL, is there a DSL router in the middle doing NAT?

You didn't show the IP address of the WAN interface [which I understand] but without it, I'm not sure if there's NAT going on in the middle of your connection. [Outside the MTK]

I haven't reviewed your post super carefully, but if you've followed the Wiki, or Sowell's walk-through - I'm pretty sure it's right and you need to start looking outside the MTK/Windows client for problems. [I've setup many using the Wiki setup, and I know it works.]

Oh, and don't use CHAP1 it's very insecure, IMO. MS-CHAP2 is much better.

-Greg

I got the client to work that was already on the LAN subnet of the mikrotik (192.168.1.0/24). So it wasn't coming from the WAN side of the mikrotik. I did this just to see if the mikrotik was at fault and if it was WAN related. Since it worked I know there must be something wrong with the WAN side of the mikrotik. Cox Communications Cable is installed here and a static WAN ip is assigned to ether1 of the mikrotik. I can ping the interface and I have also setup a Terminal Services 3389 forward which works great, so I know that it's hitting the mikrotik directly. This is why I'm at a dead end as to why clients from different sites can't connect.

do you know if there are any other pptp clients to try out besides the built in windows one?

Well guys I'll be honest and say that it doesn't seem like the clients are even hitting the router when performing the pptp connection. This really baffles me because I have this router on the edge connected to cox's modem with a static IP from Cox. When I ping the WAN ip and have the packet sniffer running I do see the icmp requests arrive, so I know that traffic is hitting it directly. so it just doesn't compute why these pptp connections wouldn't even show up in the sniffer or through the mikrotik logs.

any more ideas would be very welcome. could this be a bug in version 5.6 of the mikrotik? otherwise I could do vpn passthrough and setup RRAS on my 2008 server. What would be required on the router for this?

thanks

If you connected via the LAN [another port on the RB] then it's one of two things.

1) Something in the MTK is blocking connections to the WAN port. Firewall rule is a prime example here.
2) Something in the path is blocking PPTP connections.

I've given you some hints on #1 - but I'm not sure how you tried to evaluate that.

#2 is a known issue with some cable modems.
[I'm in comcast territory and these options wreak havok on VPN's.]

Here's how they appear in some of the devices I've seen:
-Disable "Firewall for True Static IP Subnet Only"
-Disable "Gateway Smart Packet Detection"

So, I'd probably try a couple of things.

#1. Disable all firewall rules. This should allow all traffic to flow. [This is much like the three allow rules I gave above, but I'm not convinced you have correctly applied that suggestion.]

Assuming PPTP really IS configured properly [and there's not some other conflicting issue, if you don't see a connect or traffic, then you have a problem in option #2.

--It's not a BUG in MTK, not if you can connect PPTP via an alternate port. [i.e. Eth 1,2,3 instead of eth0]
--It's not a problem with the Windows client, if you can connect in one way. [Unless you've got a windows/software firewall that filters differently in one situation vs another. You're not using something like Norton 360 are you? (forbid!)]

-Greg

If you connected via the LAN [another port on the RB] then it's one of two things.

1) Something in the MTK is blocking connections to the WAN port. Firewall rule is a prime example here.
2) Something in the path is blocking PPTP connections.

I've given you some hints on #1 - but I'm not sure how you tried to evaluate that.

#2 is a known issue with some cable modems.
[I'm in comcast territory and these options wreak havok on VPN's.]

Here's how they appear in some of the devices I've seen:
-Disable "Firewall for True Static IP Subnet Only"
-Disable "Gateway Smart Packet Detection"

So, I'd probably try a couple of things.

#1. Disable all firewall rules. This should allow all traffic to flow. [This is much like the three allow rules I gave above, but I'm not convinced you have correctly applied that suggestion.]

Assuming PPTP really IS configured properly [and there's not some other conflicting issue, if you don't see a connect or traffic, then you have a problem in option #2.

--It's not a BUG in MTK, not if you can connect PPTP via an alternate port. [i.e. Eth 1,2,3 instead of eth0]
--It's not a problem with the Windows client, if you can connect in one way. [Unless you've got a windows/software firewall that filters differently in one situation vs another. You're not using something like Norton 360 are you? (forbid!)]

-Greg

1) Something in the MTK is blocking connections to the WAN port. Firewall rule is a prime example here.
2) Something in the path is blocking PPTP connections.

I've given you some hints on #1 - but I'm not sure how you tried to evaluate that.

here is the firewall rules in affect. I've been allowing these rules you suggested since yesterday.



In regards to option #2 I the cox modem is dumb and simply changes the signal into cox's system. I cannot configure it at all.

Just got off the phone with cox and they verified that the cisco modem is wide open and no ports are being blocked. this is a business account.

Then you need to start looking at other things.

Mangle rules.
NAT rules

I seriously doubt there is a bug, and the RB sees every port, essentially the same. There's no difference between one port and another.

So, if it connects on eth2, and not on eth0, then you must have something configured on eth0 that's different than eth2.
Start really tearing into things that are different on the two ports. [Most of the time, you don't need to delete them, just disable them.]

(And I'd feel better if you connected the laptop to the WAN port, and static assigned an IP there. Set the gateway to be the RB and the RB's gateway to be the laptop. Then try to connect. If that doesn't work, then there's a config on the RB that's the problem.

If it does work, then you know it's *not* the RB.)

Usual culprits are firewall rules.
NAT and or Mangle could impact things too, depending on what's happening.

If you have log rules in the FW looking for PPTP packets (TCP 1723 and GRE *protocol* 47) - if you're not seeing anything hit those then, I'm not sure what's wrong. I could probably tear things down more, but I simply don't have time right at the moment.

But start looking at what's different in your config between the working PPTP connect port and the one that doesn't.

-Greg

Then you need to start looking at other things.

Mangle rules.
NAT rules

I seriously doubt there is a bug, and the RB sees every port, essentially the same. There's no difference between one port and another.

So, if it connects on eth2, and not on eth0, then you must have something configured on eth0 that's different than eth2.
Start really tearing into things that are different on the two ports. [Most of the time, you don't need to delete them, just disable them.]

(And I'd feel better if you connected the laptop to the WAN port, and static assigned an IP there. Set the gateway to be the RB and the RB's gateway to be the laptop. Then try to connect. If that doesn't work, then there's a config on the RB that's the problem.

If it does work, then you know it's *not* the RB.)

Usual culprits are firewall rules.
NAT and or Mangle could impact things too, depending on what's happening.

If you have log rules in the FW looking for PPTP packets (TCP 1723 and GRE *protocol* 47) - if you're not seeing anything hit those then, I'm not sure what's wrong. I could probably tear things down more, but I simply don't have time right at the moment.

But start looking at what's different in your config between the working PPTP connect port and the one that doesn't.

-Greg

I only have two ports active on this thing. ether1 and ether2. so yes, from a workstation within the LAN (192.168.1.0/24) of this mikrotik, the vpn sets up just fine. so this means it's going through ether2-master-local port. ether1-gateway is WAN and ether2-master-local is the LAN. here is how all that looks. I would be willing to setup a remote session with you so you can see just how strange this all is, if you have the time. let me know

thanks







Here is how my firewall mange and nat rules look. no rules on mangle. nat i'm masquerading and then I have "port forward" rules for the rest

It's really unlikely that I'd have time anytime soon.

Still, I think your best bet is to look and see what's different between the two port configurations.

The things I've asked you to do, really shouldn't take more than 30 minutes or so. Yes, they are a pain. But they are invaluable in narrowing down what exactly is the source of the problem.

I know Cox has assured you they aren't part of the problem, and perhaps they're right. But I wouldn't be betting large sums of money on it.

The laptop hookup to the WAN side will test that.

One you know the result of that - then you can focus on a single issue.
Either it works, and you know it's Cox's equipment, or it doesn't and you know it's a configuration issue on the MTK.

Assuming it's the second, look at what configuration you have on the ether1-gateway vs ether2-master-local.
I can't see what your dst-nat rules are, but how about disabling all of those? [Again, it's a two second try. Literally.]
Same with mangle rules. [You'll need to keep one for the WAN-LAN NAT stuff, but disable anything else.

Once you've tried that, let us know and we'll see if we can find anything else.

-Greg

It's really unlikely that I'd have time anytime soon.

Still, I think your best bet is to look and see what's different between the two port configurations.

The things I've asked you to do, really shouldn't take more than 30 minutes or so. Yes, they are a pain. But they are invaluable in narrowing down what exactly is the source of the problem.

I know Cox has assured you they aren't part of the problem, and perhaps they're right. But I wouldn't be betting large sums of money on it.

The laptop hookup to the WAN side will test that.

One you know the result of that - then you can focus on a single issue.
Either it works, and you know it's Cox's equipment, or it doesn't and you know it's a configuration issue on the MTK.

Assuming it's the second, look at what configuration you have on the ether1-gateway vs ether2-master-local.
I can't see what your dst-nat rules are, but how about disabling all of those? [Again, it's a two second try. Literally.]
Same with mangle rules. [You'll need to keep one for the WAN-LAN NAT stuff, but disable anything else.

Once you've tried that, let us know and we'll see if we can find anything else.

-Greg

Well we figured it out. I would love to come give you a big hug and kiss. haha just kidding. after you said check the NAT entries I disabled them all and it worked. I then enabled them one by one to see where the problem was at and it ended up being the problem from the 3389 tcp rdp forward.



I also had to enable the 1723 and 47 tcp for pptp and gre coming into the firewall once I removed all the allow entires for forwarding, input, and output to lock things down more.

<Fred Rogers voice> See, I knew you could. </Fred Rogers voice>

Good job. That trick of enabling and disabling rules is invaluable as you're trying to hack your way through a problem.

Also very good, is LOG action rules - which do nothing other than log the packet patch to the logs.

Glad you found it.

[And instead of a hug and kiss, how 'bout Karma? It's to the left, over there <---]


-Greg

<Fred Rogers voice> See, I knew you could. </Fred Rogers voice>

Good job. That trick of enabling and disabling rules is invaluable as you're trying to hack your way through a problem.

Also very good, is LOG action rules - which do nothing other than log the packet patch to the logs.

Glad you found it.

[And instead of a hug and kiss, how 'bout Karma? It's to the left, over there <---]


-Greg

gave the karma.

Also very good, is LOG action rules - which do nothing other than log the packet patch to the logs.

so you mean setup an input rule that has the action as log and no other settings to see all packets incoming to the router? I thought I enabled this when things were not working but I still didn't see the packets coming from the address of where my workstation was located.

Thanks for the Karma

---
Log rules.
Yes, they will show some details of the packets that match the rule.
Input/Output/Forward.

Without thinking about it much, I'd guess the rule simply didn't match. Perhaps the dst-nat rule changed the packet so it didn't match as an "input" since it was re-directing it inside. [I'm not sure that's correct, just a thought. I'd have to tinker to see if I'm right, and look at the packet flow diag...]

However, you get the idea.

-Greg

Hi, I'm sorry to resurrect this thread, however because my experience at the moment is pretty much exactly the same I thought I would use this thread and it's current info rather than start a new one. I have tried to follow this thread, as well as the tutorial already mentioned and then a couple of others. My settings are roughly the same as the original poster's but I can't seem to find the resolution that he has. Where he found the problem in his NAT translation I can't. My NAT settings are only

0 chain=srcnat action=masquerade src-address=192.168.1.0/24

and firewall filters:

0 ;;; pptp allow
chain=input action=accept protocol=tcp dst-port=1723

1 chain=input action=accept protocol=gre

2 ;;; Accept established connection
chain=input action=accept connection-state=established

3 chain=forward action=accept connection-state=established

4 ;;; Accept related connections
chain=input action=accept connection-state=related

5 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid

6 X chain=forward action=drop connection-state=invalid

7 ;;; UDP
chain=input action=accept protocol=udp

8 ;;; Allow limited pings
chain=input action=accept protocol=icmp limit=50/5s,2

9 ;;; Drop excess pings
chain=input action=drop protocol=icmp

10 ;;; From our LAN
chain=input action=accept src-address=192.168.1.0/24 in-interface=bridge-local

11 ;;; Log everything else
chain=input action=log log-prefix="DROP INPUT"

12 ;;; Drop everything else
chain=input action=drop

13 X chain=forward action=drop

Has anyone got any ideas? Just like the original poster, I can VPN while on the LAN side but not from the Net side.

Hi, I'm sorry to resurrect this thread, however because my experience at the moment is pretty much exactly the same I thought I would use this thread and it's current info rather than start a new one. I have tried to follow this thread, as well as the tutorial already mentioned and then a couple of others. My settings are roughly the same as the original poster's but I can't seem to find the resolution that he has. Where he found the problem in his NAT translation I can't. My NAT settings are only

0 chain=srcnat action=masquerade src-address=192.168.1.0/24

and firewall filters:

0 ;;; pptp allow
chain=input action=accept protocol=tcp dst-port=1723

1 chain=input action=accept protocol=gre

2 ;;; Accept established connection
chain=input action=accept connection-state=established

3 chain=forward action=accept connection-state=established

4 ;;; Accept related connections
chain=input action=accept connection-state=related

5 ;;; Drop invalid connections
chain=input action=drop connection-state=invalid

6 X chain=forward action=drop connection-state=invalid

7 ;;; UDP
chain=input action=accept protocol=udp

8 ;;; Allow limited pings
chain=input action=accept protocol=icmp limit=50/5s,2

9 ;;; Drop excess pings
chain=input action=drop protocol=icmp

10 ;;; From our LAN
chain=input action=accept src-address=192.168.1.0/24 in-interface=bridge-local

11 ;;; Log everything else
chain=input action=log log-prefix="DROP INPUT"

12 ;;; Drop everything else
chain=input action=drop

13 X chain=forward action=drop

Has anyone got any ideas? Just like the original poster, I can VPN while on the LAN side but not from the Net side.

Do a global test and just remove all your firewall port forwarding entries along with any filtering entries and see if the tunnel comes up. so work big and get smaller in essence.

I'm glad to help, but I should warn you that PPTP is **BROKEN**
See: https://www.cloudcracker.com/blog/

I can't say that with enough vigor.

In the last three weeks a new attack on the protocol was released and it's pretty trivial to break PPTP.
[Without any attempt to insult you, IMO, you'd be a fool to continue to use PPTP in any case where security was any factor at all.]

You would be very well served to use either L2TP or OpenVPN. These are the only realistic Road-warrior VPN's that are available on Mikrotik at the moment, IMO. [SSTP seems unstable, in most releases since v5.12. Plus there's no Windows client except on Vista SP1 and newer anyway.]

There are, IMO, some serious security issues with the way Mikrotik has implemented L2TP but it's far, far better than PPTP. OpenVPN has it's own issues on Mikrotik, so it's kind of a crap-shoot about which to use ... kind of a "worse or worser" situation.

But, please unless you want pretty much anyone to break into your network by grabbing the PSK in your PPTP session - don't use PPTP.


-Greg

@marshall, I'll give it a shot. However I did try with an allow all input filter at the top of the list at one point which didn't help.

@greg, thanks, but can you point me to or provide a guide on how to set openvpn or l2tp up? But a good one please. One that will not only include the obvious setting up the ppp but will also keep the firewalling and nat settings in mind (I need the remote ip to be on the same subnet as the local) and will also help with advising on the key generating.

The L2TP docs are fairly good.
The OpenVPN docs are horrid. [Really, really horrid.]

I'm probably going to do a round-up of all the Road-warrior VPN's practically available on RoS and I may do docs for OpenVPN.

I've gone back and forth - you can probably go find my recent threads - but I was inclined to like OpenVPN in general.
I was worried about RoS's OpenVPN hack-job though.

IMO, turns out I was right to be concerned. Throughput is crazy odd, and Mikrotik refuses to respond to the inquiry about it. [Typical, IMO]

They claim "it's supported" - but it really isn't. [Perhaps it's supported on a level that's equal to other VPN tunnels like IPSec - which doesn't allow you to to IPSec policy matching - so it's impossible to tell if traffic came over an IPSec tunnel.]

Speaking of IPSec policy matching: that's the prime problem I see with L2TP and IPSec for road-warrior support.

For L2TP - you can't tell if the L2TP session came in wrapped in IPSec, or just a direct connect via L2TP to 1701/UDP. [You *really* don't want people connecting direct - an open L2TP session is as vulnerable as PPTP, since it's MS-ChapV2.]
Further, you want to rely on both the IPSec PSK and the PPP credentials for security, and you don't get that with a direct L2TP connect.
Lastly, you can't tell if the user simply connects to IPSec directly instead of L2TP inside IPSec.
-Asked for some work-arounds that might mitigate this. "Nope" was essentially the reply - "we might fix that someday."

So, I've finally gone back to OpenVPN. It sucks on RoS - but I figure if I get desperate I can roll out a Linux/Ubuntu box that just handles OpenVPN if I run into terrible performance problems. [In my testing, a RB450G will throughput TCP at about 8Mb/s @ 50% CPU utilization. I couldn't get it to crank more - but the CPU wasn't maxed out either. Kind of an odd situation. Another thing Mikrotik won't respond to.]

---
So, I think L2TP is probably OK for small numbers of users and realizing the problems. I'm not choosing to use it, but it was my next choice.
I generally think OpenVPN is the best choice for interop and open support on many platforms etc. I'm not sure it's the best choice on RoS, due to severe implementation problems however. [Will depend on pipe saturation [TCP over TCP issues] and other variables. But I think it can work ok, and has fewer problems than some of the other VPN's on ROS. Like I've said before, a "worse or worser" kind of situation - which is unfortunate.

SSTP will probably get fixed sometime too - which works for Vista SP1 and higher.

---
If you're willing to wait a week or two, I'll see about doing a quick and dirty set of docs for OpenVPN. [I'll be dammed, though, if I post them here. Mikrotik can't be bothered to write up their own docs, and unless I get paid, they're not getting mine.] So they'll probably get posted on my website - but I'll post back here if I get them up.

You're welcome to bug me in a week to see how things are going if you like.

Best wishes,
Greg

Thanks for the info Greg, you really do go out of your way. I do get the feeling that Mikrotik as a company has upset you I wonder if I'll develop that same feeling one day. For now I'm just happy to be using hardware that can actually help me achieve what my imagination comes up with (in most cases). I have, however, definitely learnt a lot about the general VPN support which is helpful.

I think from your recommendations I'd give OpenVPN another shot, so I'll wait a week to see what you can come up with, and then I'll eagerly set about implementing it. If I could just ask you to post the link in this thread so that I don't miss that you've posted it.

I think ease of use is going to be more important to me than performance, as my internet connection isn't 8mbps anyway but it is good to know what the trade off is if I were asked to implement this at work. For now I'm just going to be the road-warrior user connecting to home and this is all just a learning exercise for me.

Looking forward to your docs Greg. Thanks again.

Without going on too long a rant about how MikroTik does things and why it bothers me, let me just say this:

I would absolutely LOVE for MikroTik to do really well as a company. I've spent, literally, well more than a hundred hours on MikroTik - since mid-year last year.
That's non-billable time, mostly. So, figure tens of thousands of dollars invested there.

I've written some pretty elaborate scripts to handle cases I've got - and donated them free to other users who need/want them. I re-wrote the DynDNS script to be TOS compliant with Dyn's TOS - the old user-written one wasn't.

But the attitude from MikroTik just floors me.
If it's something that Mikrotik doesn't want to deal with, they'll assault you here in the forum and ignore the failings of their product.
They'll ban users who have long contributed to their success, selling their product and helping people here.
They'll angrily insist that, essentially, "what's your problem" when you are upset about, say, the 1100AHx2 only having a tiny NVRam disk. [When the old one was half a GB, and they "snuck" in the change without really telling anyone. Even the PDF's still up at the time had the half GB spec, IIRC.]
OpenVPN's implementation is really lousy - no LZO compression and no UDP data stream!?!
No Certificate revocation lists? [It's coming in V6 they say.]
The problems in IPSec [IPSec policy matching in filter rules]
The problems in L2TP.
I haven't been a user of MikroTik for 10 years say, but it's clear that recent FW releases have not been stable as in the past in many respects.

So, while I know that people confronting them over these things isn't easy, and it's got to be irritating and difficult - it's part of life when you deal with customers. And the demands/complaints I've seen really don't seem unreasonable to me. [for example, I don't have an 1100AH-X2, but I'd be pissed if I got one with a 50MB "disk" instead of a 512MB one.]

But rather than be open about issues and work to resolve them and give some help - the response is authoritarian and heavy-handed.

IMO, that won't work well for growth of the company and continued prosperity. It will work as long as there isn't any other vendors to work with - and right now there really isn't. But I don't think it's going to stay that way forever.

So, a more responsive and pleasant vendor comes along - what do you think is going to happen. Lots of customers are going to leave, IMO. And that will not be a great thing for me, or MikroTik. I don't want to lose my, more than $10K, investment in time and effort by moving to another vendor. I'd really like MikroTik to change it's attitude and ways.

Perhaps the last year has been really bad for MikroTik, but my discussions with others elsewhere who have long had dealings with MikroTik really don't seem to bear that out. In general the response has been: "Yeah, they're jerks..." with variations of "I'm glad I don't deal with them any more." or "So, they're jerks, either quit using them or quit complaining." or "Who else are you going to get that kind of stuff that cheap from? Just live with it." Notice a trend here?

My desire: For MikroTik to be successful, friendly and helpful. Implement stuff in more industry standard kinds of ways. [OpenVPN LZO and UDP support, IPSec policy matching etc.] Then I can be more confident selling their gear to customers, knowing I won't be ripping it out and replacing it with something else a year from now. My customers will be more happy, I'll make more money and be happier and MikroTik will be more stable because of it.

Just my opinion - but I'm pretty sure I'm not the only one that feels this way.

-Greg

---
If you're willing to wait a week or two, I'll see about doing a quick and dirty set of docs for OpenVPN. [I'll be dammed, though, if I post them here. Mikrotik can't be bothered to write up their own docs, and unless I get paid, they're not getting mine.] So they'll probably get posted on my website - but I'll post back here if I get them up.

You're welcome to bug me in a week to see how things are going if you like.

Best wishes,
Greg

Hi Greg,

Curious if you ever got the openvpn docs together?
I'd love to give it a try..

Thanks much,
J.

same problem, VPN work from LAN side and not working from net side....

i have two ISP's, configured as failover (with distance 1,2 and ping check)

maybe trouble in routes ? because firewall setting is basic (trying with and without many rules), NAT settings also basic, just masquerading isp1 and isp2 out interfaces

when trying to connect pptp to isp 1 ip - i see in torch this connection apeears and disappears... pptp log empty, gre protocol in firewall shows 0 packets

tryed disable all ISP2 settings (address, interface, route) - and again nothing

tryed disable all ISP2 settings (address, interface, route) - and again nothing :(

I have the same error and I am sure it's a internal BUG on v6.28.
I have many PPTP installations and I have first time a many of #807. To resolve this I just open PPTP Server and press OK - this restart pptp engine. Now works OK.

Action and reaction in log:

Well we figured it out. I would love to come give you a big hug and kiss. haha just kidding. after you said check the NAT entries I disabled them all and it worked. I then enabled them one by one to see where the problem was at and it ended up being the problem from the 3389 tcp rdp forward.

Thank you so much for this. I couldn't figure out why PPTP broke recently on a very important router. This post made me review my port forward rules and I had forgotten to add the Dst Port on a recent rule. Funny thing is the rule actually worked, it just broke PPTP. All good now.

Michael

Can I ask why you are using PPTP and not the much more secured and encrypted IPSec + L2TP?
I did set up both om my Mikrotik and Windows can connect to both solution.

More information:
https://wiki.mikrotik.com/wiki/L2TP_%2B ... r_and_a_PC