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 fileThere 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
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.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
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.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.]
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?After further testing from within the same network as the microtik I was able to connect a client just fine.
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.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?After further testing from within the same network as the microtik I was able to connect a client just fine.
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.
1) Something in the MTK is blocking connections to the WAN port. Firewall rule is a prime example here.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!)]
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 knowThen you need to start looking at other things.
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.
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.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.
gave the karma.<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 <---]
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.Also very good, is LOG action rules - which do nothing other than log the packet patch to the logs.
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.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
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.
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.
I have the same error and I am sure it's a internal BUG on v6.28.tryed disable all ISP2 settings (address, interface, route) - and again nothing :(
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.
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.