I have a small business network comprising (today) a main office, a remote office and a mobile unit. Each has a RouterOS powered router - the main office has an x86 platform, the remote office has an RB433 and the mobile uses an RB411 over 3G.

As only the main office has a fixed ip address, VPN is established using pptp - this works well and has done so for many months. Router reliability was very good - prior to the recent changes (see below) these units had had over 6 months between restarts (and those restarts were only due to power changes).

Latest innovation has been to add OSPF to enable any to any client routing from any location to any other (e.g. accessing printers etc) and to enable or facilitate easy addition of further locations (such as work-at-homers) without having to re-build the routing tables manually on each occasion.

OSPF seems to do the trick BUT the router reliability has fallen dramatically. The remote office router is now having to be re-booted once per day and the mobile similarly when in use - symptoms are that OSPF connectivity is lost, pptp goes down as does internet connectivity. No useful information apparent in the logs.

I have noticed some strange frames appearing in the logs on the PPTP interface - but these do not correlate with the outage. In fact, there a a burst of these odd frames at the start of a PPTP session and then they stop.

Any thoughts?

Best Regards

Ian Beeby

...I forgot to mention - all devices are using RouterOS 4.6 with the same release...

Ian

Just a shot in the dark here, but are you running ospf on the wan link? I'm thinking that perhaps the wan ip is being sent via ospf through the tunnel and the pptp traffic gets confused and tries to sen through the tunnel and thus bricks. Make sure the process only runs inside and on the pptp interface.

BTW, you can do IPSec tunnels for the same thing, only it will be more secure. Check the link in my signature and hit the video VPN vid

Interesting thought - I am not sure whether the OSPF is running on one interface or all - it seems to settle on the PPTP link in any event so I am not sure that this is the complete issue - but if I can work out how to constrain the OSPF to the PPTP link from the outset I'll give it a go.

It takes typically several hours before the pptp fails - it is not immediate.

I don't use ipsec as the remote stations are on dynamic ip addresses - is it possible to run ipsec with dynamic addresses? For the moment the main office has a fixed ip address but I have to pay extra for that and would sooner do away with it as it encourages attacks etc.

Best regards

Ian

I don't use ipsec as the remote stations are on dynamic ip addresses - is it possible to run ipsec with dynamic addresses? For the moment the main office has a fixed ip address but I have to pay extra for that and would sooner do away with it as it encourages attacks etc.

Generally speaking it's possible to run IPsec with dynamic addresses, but it's a real pain in RouterOS. Also, generally speaking the hub site should be running a static IP as that simplifies the spoke set up. I get the financial concerns, but a dynamic hub IP doesn't do anything at all for security. The vast majority of attacks you'll see are the result of a port scan across huge network ranges, you don't escape those by having a dynamic IP. Anyone targeting you specifically is not going to be deterred by a changing IP address. You need to protect the hub router either way, with the same mechanisms.

An update:

In case this problem is caused by OSPF getting confused by getting odd inputs from interfaces where OSPF should not be running, I have created an interface specific OSPF 'interface' on the hub router (ie one for each PPTP dial-in session) and put in a fixed equivalent on the dial-in routers. I've also taken the opportunity to enable MD5 authentication as well to avoid spurious results from any random chatter. I have also tied down the links to be point to-point, which they are literally (and I think in an OSPF sense) rather than the default broadcast.

I shall see whether this has any beneficial effect on link reliability. The mobile router is seldom required for more than a couple of hours at a time (at the moment) and the proof will be to see whether the remote office router needs to be re-booted tomorrow - which without OSPF it did not need as mentioned earlier (but then again one had to manually add routes around the network which was a pain.

Best Regards

Ian

PS - any further thoughts welcome

PPS - will consider ipsec once this matter is sorted out unless someone tells me that the problems that I have encountered are a feature of OSPF over PPTP

I'm not sure that your issues are OSPF PPTP related, as I've always done ipip tunnels/ipsec with OSPF running inside.

Well, nor am I save that the router unreliability started almost as soon as I implemented OSPF to establish routing within the network.

Since my last post I have ensured that the OSPF 'interfaces' only operate on the PPTP channels and not on the default 'all' - this _appears_ to have improved stability with the remote site router remaining on line all night without crashing and dropping the PPTP tunnel.

I am still getting some odd packets reported on the firewall on the PPTP end-point addresses which I am concerned about but these were seen _before_ OSPF was implemented.

If the router can stay up for the week I'll be pretty convinced (although I agree that I will not know _why_) that the problem was related to OSPF operating on interfaces which it was not supposed to somehow.

More when some stability, or not, is determined...

Ian

Well, progress is progress. I'm glad it appears to be operating better

Well, I should say that 24 hours is too short to be certain but I am optimistic. The remote office was still logged on (is, I should say) this evening after a whole day and night. Of course this was not too scientific a fix (because I needed a fix sooner rather than later) and I ended up doing two things:

1/ Being, as was helpfully suggested, explicit about which interface the OSPF was to operate on as opposed to accepting the default 'all'. In my router, the 'all' appeared to be dynamically translater into (e.g.) pptp_in_1, say, once an active session was established but then the same link would fall over (the pptp link) within a few hours or evenn less time whereas without the OSPF it would happily stay up for a long time - so in my case for the office router:

a) pptp_in_1; and

b) pptp_in_2; and

in the case of each remote router:

pptp_out_1 (or as applicable); and

2/ Enabling MD5 authentication to prevent OSPF sessions being started by random chatter or whatever might do this (I am really doubtful that this could occur but in any event I gather that this is a good idea where there may potentially be a dial in vulnerability which is arguably the case with my network at present).

I do intend to look at replacing pptp with ipsec where possible in due course as I accept that this is more secure - but for the moment I want to get what is working to work well.

I will report back again at the end of the week or sooner if I encounter problems.

Best Regards and thanks for all the help...

Ian

You will still need a tunnel like ipip since a straight ipsec tunnel won't propagate multicast traffic. IPSec is just more secure than pptp alone.

Its been up for a week now with no problems - so I think that the issue has been resolved.

To recap: The inter-router pptp links started to fail shortly after the implementation of ospf to broadcast routes from the hub router to the peripheral routers. The ospf sessions had been implemented hastily.

Following advice obtained here (for which many thanks folks:-) the following changes were implemented on the ospf setup:

a) The OSPF sessions were set up PER INTERFACE - that is to say, on the hub router, one OSPF 'INTERFACE' per pptp in-bound 'interface';

b) The OSPF sessions were declared 'POINT-TO-POINT'; and

c) For good measure, MD5 authentication was enabled on the OSPF sessions to avoid any errored frames causing a problem (although there was no suggestion that this might be actually occurring.

Since this time the main tunnel between the head office and the main sub-office has been up for a week whereas prior to these fixes it was going down after a few hours and requiring a router reboot. Ad-hoc mobile site sessions have been perfectly reliable as opposed to occasionally dropping out within a couple of hours, again requiring a reboot.

It is not clear whether this unreliability is a bug or whether it was a breach of the rules to just enable OSPF on 'all' interfaces (which is the default) but in any event, the above measures seems to have resolved the problem.

Next issues to tackle: a) firewall hits occurring from seemingly within the pptp links; and b) ipip over ipsec to be more secure than pptp.

Try down grading to 4.5. We noticed that once we upgraded to 4.6 a couple of our router boards(about 5 that I have personally observed) were falling over(100% cpu and dynamic routing breaks). We think its to do with OSPF and your post makes us more certain about this. Though it only seemed to happen on routerboards that were running OSPF. The others that were just running BGP seem to be fine. 4.5 does not seem to have this problem.

thaak,

You may be right but my system has now been up for 10 days with no problems - no heavy CPU occupancy or anything like that. The PPTP tunnel occasionally drops as one site is wirelessly connected but then all gets restored automatically and with no mess and no fuss once the link is reestablished by the wireless interface.

I am not seeing the sort of problem that you report at all.

HOWEVER - you may wish to look at how your OSPF interfaces are defined. It may be that 4.6 provides some feature which tighens up the 'syntax' in the OSPF in such a way that loosely configures networks suffer problems.

I don't know - its not my bag - all I can report is that my network seems to be back to normal with the added benefit of routing being updated as remote sites join and leave:-)

We've got it fairly tightly set. Though yes it seems to be and odd one that when it has hit us its hit a couple at one time. Then seems fine for a while. We have quiet a few sites and some remote so the chance that it might happen is unfortunately not a problem. It could be the interaction between OSPF and BGP. As we use BGP for eBGP and OSPF for iBGP.

Were waiting for 5 to become stable then going to look again.

thaak,
Are you using any kind of encryption? We have the same issue and have 300+ locations. OSPF error "discarding packet locally originated" flows through the logs every few minutes. We disabled encryption and upgraded to 4.7 (supposed to fix) and still experience the same issue, but it doesn't crash the router. Testing new encryption scheme next week as the freeze up appears to be related to using MD5/3DES for IPSec. I can keep you posted if you like.

Were not running any encryption. Its all part of Pretoria wireless user group thats spanning the city or Pretoria. We've moved off of OSPF for our backbone routing. We only using OSPF for iBGP at our high sites (at the most 5 RB's most have 3). Its on the couple that we were testing 4.6 were of the router boards fell over.