MikroTik

Posted: **Wed Oct 09, 2013 6:29 pm**

Hi,
I have been setting up a bridge between a router(750GL) and a wireless AP(RB751U-2HnD).
I have been following the guide for BCP bridging (http://wiki.mikrotik.com/wiki/Manual:BC ... _bridging))
I have then added a DHCP server on the Bridge interface on the 750GL which is also running the PPTP server.
The devices connects and communication between them works great using static IPs.
The problem is that when on the PPTP client side of things, DHCP offers never reach the clients.

I connect a computer to the RB751U-2HnD, the DHCP server on the 750GL offers a lease, and then nothing else happens. The computer seems to never recieve any lease offer...
I have now been sitting with this for about 7 hours and has no more ideas. DHCP works great on the 750GLs physical interfaces.

PS. my MikroTik skills are on a newbie level.

Apreciate any help you guys can offer.

Im running RouterOS 6.4

Posted: **Wed Oct 30, 2013 12:32 pm**

I am having the exact same problem.
Have played around with proxy-arp but that makes no difference.
Any solutions here?

Posted: **Wed Oct 30, 2013 2:53 pm**

Hi,
I downgraded my routers to 5.26 and the same setup worked fine. I did some traffic sniffing and it seems that the v.6.xx RouterOS does not forward DHCP responses via the PPTP connections for some reason.
Requests arrive, but all responses do not leave the main router through PPTP.
I will report it as a bug and hopefully they will fix it.

Posted: **Wed Oct 30, 2013 3:15 pm**

I have done some more testing.
I was using RouterOS 6.5, and was experiencing the problems explained by Lazarus.
Just no downgraded to RouterOS 5.26 and is works!!!

I will also post my findings into the 6.5 released topic, maybe somebody there has a solution.

Posted: **Thu Jul 24, 2014 7:38 am**

Did this ever get resolved ?

I am having the exact same problem

Posted: **Thu Jul 24, 2014 10:39 am**

Did this ever get resolved ?

I am having the exact same problem

This problems started somewhere around version 6.4/5 and is solved I believe in version 6.12.
I have not tested it on the latest but will do that asap.

Posted: **Thu Jul 24, 2014 11:40 am**

I have tested it and it is solved in Version 6.11.
I did not test all versions inbetween but I see no problems with the latest version, 6.17

Posted: **Thu Jul 24, 2014 12:05 pm**

I have tested it and it is solved in Version 6.11.
I did not test all versions inbetween but I see no problems with the latest version, 6.17

Thanks Rudios !

Now i just have to test all the other features we use on RouterOS 6.17 before we upgrade from our trusted 6.5

Posted: **Fri Jul 25, 2014 11:40 pm**

I just tested this very carefully and it seems to NOT work over 6.17.

Rudios, can you check this out and repeat your testing? It seems very clear to me that it's still broken.

Following is my very simple two router setup. Details are at the end.

Each router is connected via ether1 to my workbench LAN, as 192.168.1.133 and .134.
I'll call them 'left' and 'right'.

Both have a bride called bridge-tunnel, with no ports. Admin MAC set to 02:AA:AA:AA:AA:AA on the right and 02:BB:BB:BB:BB:BB on the left.

Both bridges are connected via BCP using PPTP.
Left bridge is statically assigned 192.168.40.5/24.
Right bridge is statically assigned 192.168.40.1/24
DHCP server is created on right bridge with pool 192.168.40.100-192.168.40.200.
DHCP client is created on left bridge.

Testing
------
1) Ping from left router to 192.168.40.1
2)Ping from right router to 192.168.40.5
3)Look for left bridge DHCP client to get IP address from right bridge DHCP server.

Results
====
ROS 6.17 Tests 1&2 passes, Test 3 failes
ROS 5.26 Tests 1,2 & 3 always passes.

The configuration was not changed in any way between ROS versions. I tested 6.17, downgraded to 5.24, tested, upgraded to 6.17 again and re-tested.

Here are the detailed configurations. It takes about 2 minutes to set this up.

Left router:


# jul/25/2014 15:32:08 by RouterOS 6.17
# software id = 4RFY-E9RX
#
/interface bridge
add admin-mac=02:BB:BB:BB:BB:BB auto-mac=no name=bridge-tunnel
/ppp profile
add bridge=bridge-tunnel name=profile-tunnel
/interface pptp-client
add add-default-route=no allow=pap,chap,mschap1,mschap2 connect-to=\
    192.168.1.133 dial-on-demand=no disabled=no keepalive-timeout=60 max-mru=\
    1450 max-mtu=1450 mrru=1600 name=pptp-tunnel password=tunneltest profile=\
    profile-tunnel user=tt
/ip address
add address=192.168.40.5/24 interface=bridge-tunnel network=192.168.40.0
/ip dhcp-client
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \
    interface=ether1
add default-route-distance=0 dhcp-options=hostname,clientid disabled=no \
    interface=bridge-tunnel use-peer-dns=no use-peer-ntp=no

Right router:

# jan/02/1970 00:21:04 by RouterOS 6.17
# software id = 8J2K-5ZUR
#
/interface bridge
add admin-mac=02:AA:AA:AA:AA:AA auto-mac=no name=bridge-tunnel priority=0x4000
/ip pool
add name=pool1 ranges=192.168.40.100-192.168.40.200
/ip dhcp-server
add address-pool=pool1 authoritative=yes disabled=no interface=bridge-tunnel \
    name=server1
/ppp profile
add bridge=bridge-tunnel name=profile-tunnel
/interface pptp-server server
set default-profile=profile-tunnel enabled=yes mrru=1600
/ip address
add address=192.168.40.1/24 interface=bridge-tunnel network=192.168.40.0
/ip dhcp-client
add dhcp-options=hostname,clientid disabled=no interface=ether1
/ip dhcp-server network
add address=192.168.40.0/24 gateway=192.168.40.1
/ppp secret
add local-address=192.168.80.1 name=tt password=tunneltest profile=\
    profile-tunnel remote-address=192.168.80.2

Posted: **Fri Jul 25, 2014 11:51 pm**

I had also found out that it is not working when pptp interfaces are assigned with an IP address.
Because they are to be added to the bridge, IP address is not needed.

Posted: **Sat Jul 26, 2014 12:23 am**

I had also found out that it is not working when pptp interfaces are assigned with an IP address.
Because they are to be added to the bridge, IP address is not needed.

Well, your comment above is very interesting. I always thought that local/remote pptp addresses were required to make the tunnel function. I guess that is only true if the client needs the local address for its own routing purposes to reach the server. I can see that this isn't needed if the only function of the tunnel is for BCP.

Since you noted the original bug over in the "bug list" thread, do you want to tell them it's still sort of broken? Or should I do that? Is this really a bug, or an "undocumented feature (i.e. Don't use local/remote IP addresses if tunnel is used for BCP") ?

Posted: **Sat Jul 26, 2014 12:37 am**

Just ask support.
I can not remember how the situation was with versions between 6.4 and 6.11

Posted: **Wed Mar 01, 2017 12:45 am**

As of 6.38.1 it does not work.... And I cannot remove the L2TP tunnel endpoint addresses, they get assigned regardless of profile/username settings.

I'm using EoIP, but I *really* need for native BCP bridging to carry the DHCP.

Posted: **Fri Nov 10, 2017 4:47 am**

do not use Local and Remote Addresses on PPTP or L2TP server config when bridging both ends or it won't pass DHCP. I don't know why.

Posted: **Fri Feb 09, 2018 5:23 pm**

Hi Guys, I have the same issue. 6.39.2 we do not use Local and Remote Addresses on PPTP server. Any suggestion?

Posted: **Wed Aug 01, 2018 11:07 am**

I was having the same problem as above, DHCP leases were being offered to clients at the remote end of the BCP link but the client never received the offer.

In my scenario I was adding BCP tunnels to an existing site. I fixed it by changing the existing IP address assignment for the physical LAN port at the main site (in my case ether6) to the BCP bridge instead. As soon as I did that and refreshed the remote site connections everything started working.

Hope that helps anyone with this problem in the future (or the past!). Iv'e been trying to figure this out for the past month or so.

Steve

Posted: **Wed Sep 05, 2018 6:53 pm**

Hi,

Your thought is reasonable, from my survey, Network Bridge is very similar to the Internet Connection Sharing (ICS) feature, but they're not the same.

When we use Internet Connection Sharing (ICS), we will convert our computer into a router, which uses a built-in DHCP server to assign IP addresses to computers participating in ICS. It also offers Network Address Translation (NAT) that allows multiple devices to connect to the network using the ICS host as the middle man.

On the other hand, Network Bridge doesn't turn the host computer into a router and you won't get Network Address Translation. It only provides a medium (bridge) in which other devices can connect directly to the network and obtain the same IP address scheme every other computer connected to the network is using.

Posted: **Wed Sep 05, 2018 10:49 pm**

As per normal UDP operation, the tunnel initiator selects an available UDP port and sends port number 1701 to the UDP destination. In the reply, the destination port number is the same as the source port number that is used in the incoming UDP header. The source port is set on the basis of any free port that is found. After the source and destination ports are established, the ports must remain the same for the duration of the tunnel. The source and destination port numbers are always set to UDP port number 1701.

MikroTik

Problem with DHCP over BCP bridging

Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging

Re: Problem with DHCP over BCP bridging