Community discussions

MikroTik App
 
simonefil
just joined
Topic Author
Posts: 23
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Problems to reach routerboard with PPTP tunnel

Sat May 15, 2021 2:26 pm

Goodmorning everyone.
Introduction: I insert a picture of the network connections with the names of the devices named below Image
I have a routerboard (in picture called rb2) with 4G connectivity with ISP IP under NAT. To reach its interface from the outside I thought to create a PPTP tunnel between it and my main routerboard (in picture called rb1).
I created a PPTP server on rb1 with these parameters (cleaned):
/ppp profile
add bridge=bridge1 local-address=192.168.3.75 name=hap01
/interface pptp-server server
set enabled=yes
/ip address
add address=192.168.3.75/24 interface=bridge1 network=192.168.3.0
/ppp secret
add local-address=192.168.3.75 name=hap01 password="***************" \
    profile=hap01 remote-address=192.168.3.43 routes=\
    "192.168.1.0/24 192.168.3.75" service=pptp
set name="rb1"
The IP 192.168.3.75 is the IP of rb1 which corresponds to the gateway of the rb1 LAN. the IP 192.168.3.43 is the IP I want to assign to the PPTP interface on the rb2.

On rb2 I created a PPTP client with these parameters (cleaned):
 
/interface bridge
add name="bridge LAN"
add name="bridge VPN"
/interface pptp-client
add add-default-route=yes connect-to=[rb1 ISP Public IP] disabled=no name=VPN-Client \
    password="***************" user=hap01
/ip pool
add name=dhcp_pool1 ranges=192.168.2.100-192.168.2.200
/ip dhcp-server
add address-pool=dhcp_pool1 disabled=no interface="bridge VPN" name=dhcp2
add bridge="bridge VPN" interface=ether4 multicast-router=disabled
add bridge="bridge VPN" interface=ether5 multicast-router=disabled
set name="rb2"
I put the PPTP interface to masquerade and connecting any device on the rb2 bridge ports everything works and I navigate using the ISP public IP of rb1.
With a pc connected to rb2 LAN (in picture called PC2) trying to ping a device connected to the rb1 LAN (in picture called NAS) it answers and I can access it. From rb1 terminal trying to ping 192.168.3.43 (PPTP interface rb2) it responds, while if I try to ping it from a device under the rb1 LAN (in picture called PC1) it does not respond. I don't even see the IP 192.168.3.43 in the rb1 ARP list.
What am I wrong? I have minimized the exposure of my configurations to avoid confusion. If you need further details on configurations, please ask
Thanks so much everyone
 
tdw
Forum Veteran
Forum Veteran
Posts: 962
Joined: Sat May 05, 2018 11:55 am

Re: Problems to reach routerboard with PPTP tunnel

Sat May 15, 2021 9:33 pm

ARP only applies to IP-over-ethernet. If you overlap subnet address on ethernet and non-ethernet interfaces then use proxy-arp on the ethernet interface, or parent bridge if the interface is a member of a bridge, so the Mikrotik replies to ARP requests from ethernet-connected devices on behalf of the non-ethernet-connected ones.

You should not need NAT, just appropriate routes at both ends - a Mikrotik VPN server will not push routes to a client.

Presumably 192.168.1.0/24 is some other network not shown - the PPP secret routes statement is missing a distance, and you can use a placeholder for the gateway, so routes="192.168.1.0/24 0.0.0.0 1"

With incomplete configurations there may be other issues. Finally, don't use PPTP as MSCHAPv2 and MPPE are insecure.
 
simonefil
just joined
Topic Author
Posts: 23
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Problems to reach routerboard with PPTP tunnel

Sun May 16, 2021 12:09 am

ARP only applies to IP-over-ethernet. If you overlap subnet address on ethernet and non-ethernet interfaces then use proxy-arp on the ethernet interface, or parent bridge if the interface is a member of a bridge, so the Mikrotik replies to ARP requests from ethernet-connected devices on behalf of the non-ethernet-connected ones.

You should not need NAT, just appropriate routes at both ends - a Mikrotik VPN server will not push routes to a client.

Presumably 192.168.1.0/24 is some other network not shown - the PPP secret routes statement is missing a distance, and you can use a placeholder for the gateway, so routes="192.168.1.0/24 0.0.0.0 1"

With incomplete configurations there may be other issues. Finally, don't use PPTP as MSCHAPv2 and MPPE are insecure.
Thank you so much for your answer.
The 192.168.1.0/24 network is a secondary network of rb2 which does not concern the PPTP tunnel (it comes out with the natted IP of the SIM 4g).
I changed the PPTP routes as suggested by you:
Image

But the situation does not change. Trying to ping from the windows prompt the result is this:
C: \ Users \ simon> ping 192.168.3.43

Ping 192.168.3.43 with 32 bytes of data:
Reply 192.168.3.107: Destination host not reachable.
Reply 192.168.3.107: Destination host not reachable.
Reply 192.168.3.107: Destination host not reachable.
Reply 192.168.3.107: Destination host not reachable.

Ping statistics for 192.168.3.43:
     Packets: Transmitted = 4, Received = 4,
     Lost = 0 (0% lost),
     
As you can see I ask for the ping on IP 3.43 but I am answered 3.107 (I don't know why)
 
tdw
Forum Veteran
Forum Veteran
Posts: 962
Joined: Sat May 05, 2018 11:55 am

Re: Problems to reach routerboard with PPTP tunnel  [SOLVED]

Sun May 16, 2021 12:41 am

I would expect 192.168.3.107 is the address of your PC, did you set arp=proxy-arp on bridge1

The routes parameter was a separate issue I noticed.
 
simonefil
just joined
Topic Author
Posts: 23
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Problems to reach routerboard with PPTP tunnel

Sun May 16, 2021 1:48 pm

I would expect 192.168.3.107 is the address of your PC, did you set arp=proxy-arp on bridge1

The routes parameter was a separate issue I noticed.
I have enabled the proxy arp on bridge1 interface and now it works!! Thank you so much for your help! You have been very kind :)
 
simonefil
just joined
Topic Author
Posts: 23
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Problems to reach routerboard with PPTP tunnel

Mon May 17, 2021 10:29 am

I would expect 192.168.3.107 is the address of your PC, did you set arp=proxy-arp on bridge1

The routes parameter was a separate issue I noticed.
Forgive me, I take your availability again to ask you for a little advice.
Now from the PCs connected to the subnet 192.168.3.0/24 I can reach the web interface (and winbox) of the rb2 connected by VPN tunnel. Now I would like to reach the tb2 web interface also from the outside through my public ip and dedicated port. Therefore I created this rule:
/ip firewall NAT
add action=dst-nat chain=dstnat comment="rb1 Management WAN" dst-port=11500 \
    protocol=tcp to-addresses=192.168.3.43 to-ports=80
which I also use to access other devices in the 192.168.3.0/24 subnet and they work. Unfortunately this time I can't reach rb01. Why? Do I have to apply any particular rules? (The http and winbox services on the rb01 are activated without restrictions)
Thanks again for your help
 
tdw
Forum Veteran
Forum Veteran
Posts: 962
Joined: Sat May 05, 2018 11:55 am

Re: Problems to reach routerboard with PPTP tunnel

Mon May 17, 2021 4:47 pm

That NAT rule will send any packets for TCP port 11500 to 192.168.3.43 (hint, you may wish to qualify the rule for packets arriving from the WAN interface or interface list, otherwise none of your LAN devices will be able to access anything on the internet using that port), however the source address is unchanged so rb2 will send they reply through its WAN interface, not the VPN tunnel.

There are a couple of solutions, you can either add routing tables and connection/routing marks on rb2 to return traffic arriving through the VPN interface to be returned through the same interface, or you can use a src-nat rule on rb1 so the source address of the packets arriving at rb2 is the rb1 interface address instead of the original public address. It may seem odd but you can apply both src-nat and dst-nat to a connection, you just have to watch which addresses and ports you use as qualifiers as dst-nat is applied in prerouting and src-nat in postrouting
 
simonefil
just joined
Topic Author
Posts: 23
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Problems to reach routerboard with PPTP tunnel

Mon May 17, 2021 8:17 pm

That NAT rule will send any packets for TCP port 11500 to 192.168.3.43 (hint, you may wish to qualify the rule for packets arriving from the WAN interface or interface list, otherwise none of your LAN devices will be able to access anything on the internet using that port), however the source address is unchanged so rb2 will send they reply through its WAN interface, not the VPN tunnel.

There are a couple of solutions, you can either add routing tables and connection/routing marks on rb2 to return traffic arriving through the VPN interface to be returned through the same interface, or you can use a src-nat rule on rb1 so the source address of the packets arriving at rb2 is the rb1 interface address instead of the original public address. It may seem odd but you can apply both src-nat and dst-nat to a connection, you just have to watch which addresses and ports you use as qualifiers as dst-nat is applied in prerouting and src-nat in postrouting
Hi!
Thank you for your answer. I already have a routing mark and routing tables to route the return traffic from the VPN to it. I post you the most complete configuration of my hap2 so that you can understand:
/interface lte
set [ find ] name=lte1
/interface bridge
add name="bridge VPN"
add name=bridgeLAN
/interface ovpn-client
add certificate=cert_export_client.crt_0 cipher=aes256 connect-to=***.***.***.*** \
    mac-address=**:**:**:**:**:** name=open-vpn_byte-solutions password=\
********************** port=1190 user=hap01
/interface bridge port
add bridge=bridgeLAN interface=ether2 multicast-router=disabled
add bridge=bridgeLAN interface=ether3 multicast-router=disabled
add bridge=bridgeLAN interface=ether1 multicast-router=disabled
add bridge="bridge VPN" interface=ether4 multicast-router=disabled
add bridge="bridge VPN" interface=ether5 multicast-router=disabled
/ip address
add address=192.168.1.1/24 interface=bridgeLAN network=192.168.1.0
add address=192.168.2.1/24 interface="bridge VPN" network=192.168.2.0
/ip firewall mangle
add action=mark-routing chain=prerouting new-routing-mark=LAN_to_LTE \
    passthrough=yes src-address=192.168.1.0/24
add action=mark-routing chain=prerouting new-routing-mark=LAN_to_VPN \
    passthrough=yes src-address=192.168.2.0/24
/ip firewall nat
add action=masquerade chain=srcnat out-interface=lte1
add action=masquerade chain=srcnat out-interface=open-vpn_byte-solutions
/ip route
add distance=1 gateway=192.168.42.129 routing-mark=LAN_to_LTE
add distance=1 gateway=open-vpn_byte-solutions routing-mark=LAN_to_VPN
The first solution that you recommend me, that of adding routing tables and connection / routing marks on rb2, haven't I already created it?
As you can see I listened your advice, I deleted the PPTP connection and I activated an OpenVPN. Much safer.
 
simonefil
just joined
Topic Author
Posts: 23
Joined: Tue Apr 13, 2021 9:22 pm
Location: Bergamo - Italy
Contact:

Re: Problems to reach routerboard with PPTP tunnel

Wed May 19, 2021 10:38 pm

That NAT rule will send any packets for TCP port 11500 to 192.168.3.43 (hint, you may wish to qualify the rule for packets arriving from the WAN interface or interface list, otherwise none of your LAN devices will be able to access anything on the internet using that port), however the source address is unchanged so rb2 will send they reply through its WAN interface, not the VPN tunnel.

There are a couple of solutions, you can either add routing tables and connection/routing marks on rb2 to return traffic arriving through the VPN interface to be returned through the same interface, or you can use a src-nat rule on rb1 so the source address of the packets arriving at rb2 is the rb1 interface address instead of the original public address. It may seem odd but you can apply both src-nat and dst-nat to a connection, you just have to watch which addresses and ports you use as qualifiers as dst-nat is applied in prerouting and src-nat in postrouting
In these days I have done several tests, specifically on the rb1. I think it's some NAT problem on rb1 that doesn't get the request to the tunnel interface on rb2. I created some srcnat rules but all of them were unsuccessful. I still need your help.
Thanks for the advice you can give me

Who is online

Users browsing this forum: No registered users and 129 guests