Problems with PPTP on Mikrotik

Question

VPN

Good time of the day. The essence of the problem is as follows: there is a PPTP tunnel, the client is Mikrotik, the server is a rather exotic Watchguard Firebox. When establishing a udp(sip) connection through the tunnel, something strange happens in the Reply Dst. The address of this connection is written not by ip from the VPN subnet, but by the ip assigned to the wan interface, and of course there is no response to the packets. If you manually reset this UDP connection in Mikrotik, then the correct address is substituted on the new connection and everything works until the next reconnect. I tried to update the firmware to 5.21 (the last one seems to be) before that it was 5.17, everything is the same.

Answer 1

I know this is a bit late, but maybe it will help someone. :)
In Mikrotik, you need to create an accept rule in firewall nat before the masquerade rule:
an example ,
ip firewall nat add src-address=192.168.88.0/24 dst-address=192.168.0.0/24 action=accept
and this rule must be mandatory before the nat (masquerade) rule. The point is that packets coming from the local network 192.168.88.0/24 to the vpn network 192.168.0.0.24 will not reach the nata rules, because it will just go through the accept rule.

Answer 2

Well, I think it's in Mikrotik. I just did a test, connected via pptp from Mikrotik, made this route default and connected to asterisk, Zoiper soft background.
Here's what it gives on the connection:
sip: [email protected]:5060
and the calls go through normally. the address 192.168.25.X is just the address of which Mikrotik received via pptp from the server.
pptp server on CentOS.
Most likely you have a problem with your "exotic Watchguard Firebox".

Answer 3

There was a problem described in the question. He described in detail the settings of Aster and Mikrotiks in the central and remote offices on his page _blog.erofeevonline.ru
In short, the essence is as follows:
1. Correctly create clients (local and remote address)
2. Prescribe routes on remote Mikrotiks
3. Chop off at the central Sip helper
4. We look in the settings of the remote router IP-->Firewall--NAT if there is a masquerade towards the central one. If so, then that would be the problem. This means that the remote router replaces the client's address with its external one.