problem with NAT on tile

RouterOS General
1

Hi,

I have some pptp connection to my router:

Flags: X - disabled, I - invalid, D - dynamic
 #   ADDRESS            NETWORK         INTERFACE
 1   XX.63.44.57/30    XX.63.44.56    sfp1
 5   10.100.0.1/24      10.100.0.0      bridge_intra
 8 D 10.201.0.1/32      10.201.0.26     <pptp-ppp_dxxxx>
 9 D 10.201.0.1/32      10.201.0.32     <pptp-ppp_exxx>
10 D 10.201.0.1/32      10.201.0.16     <pptp-ppp_mxxx>
11 D 10.201.0.1/32      10.201.0.12     <pptp-ppp_sxxx>
12 D 10.201.0.1/32      10.201.0.19     <pptp-ppp_mxxx>
13 D 10.201.0.1/32      10.201.0.14     <pptp-ppp_zxxx>
14 D 10.201.0.1/32      10.201.0.21     <pptp-ppp_gxxx>
15 D 10.201.0.1/32      10.201.0.13     <pptp-ppp_rxxx>
16 D 10.201.0.1/32      10.201.0.20     <pptp-ppp_axxx>
17 D 10.201.0.1/32      10.201.0.31     <pptp-ppp_sexxxx>
18 D 10.201.0.1/32      10.201.0.29     <pptp-ppp_txxx>
19 D 10.201.0.1/32      10.201.0.6      <pptp-ppp_szxxx>
20 D 10.201.0.1/32      10.201.0.8      <pptp-ppp_maxxx>
21 D 10.201.0.1/32      10.201.0.2      <pptp-ppp_offxx>
22 D 10.201.0.1/32      10.201.0.15     <pptp-ppp_orxxx>

/ip firewall nat add action=masquerade chain=srcnat dst-address=10.201.0.0/24 out-interface=all-ppp src-address=10.100.0.0/16

When I ping 10.201.0.15 from 10.100.0.254 nat doesn’t work :frowning:
sniffed the pptp interface and the src address is XX.63.44.57 not 10.201.0.1 !!!

why ??? is it a bug???

regards, Gabor

2

All the pptp-ppp-xxxx interfaces are clients connecting in?

If it’s a client to server setup (rather than site-to-site), then there should be no masquerade rules needed (other than the normal masquerade rule for traffic going out the WAN interface)

If you ping from 10.100.0.254 to 10.201.1.15, the ping will make it the client. But when the client replies to 10.100.0.254, it’ll send the reply out its default route unless you have specified a route on the clients to send 10.100.0.0/24 traffic down it’s PPTP interface. Or if you’ve set clients to route all traffic down the VPN then it’ll work.

3

Ok, the problem solved. Thank you for the support!

Problem was (is) that the packets which are going to the ppp interface go to the default gw. This happens because the ppp interface doesn’t exists yet (for example on startup) and “bad” item created in the connection tracking table. When the ppp interface goes up the connection goes to the wrong way until the old connection is not deleted (by hand).

regards, gcsuri