Every tower has a dhcp server over a bridge interface. This bridge interface includes a eoip tunnel to the pppoe access concentrador, that are bridged togerther in the pppoe server..
The problem is that I get ip addresses from dhcp servers in other towers over the entire network.
please can you tell me the way to filter dhcp?, I’m new in mikrotik filtering issues.
One question more, if I block DHCP in a bridge interface, the customer side of the tower will not get ip from the dhcp server?
PPPoE server – EOIP – Tower Router ------Customers.
All customers and eoip tunnel are in the same bridge in the tower router. When customer log the first time in the network then get an ip address from dhcp. From this IP only can get access to a web server to register in a radius server account. When the process is done, then sets up the pppoe interface with the given data and gets full access to internet.
If your DHCP server is running on the tower router that has the bridge interface, then constructing a bridge filter rule on the forward chain is not going to prevent the router itself from sending and receiving DHCP packets via the bridge, since those would only hit the input and output chains (originating from and directed at the router).
i have conneceted 2 “sites” via EoIP throu an OVPN Tunnel
on router SiteA i have a bridge (eth2-5 + EoIP-SiteB)
on router SiteB i have a bridge (eth2-5 + EoIP-SiteA)
on both Sites there are 2 vPC clients with dhcp config. (connected via Switch)
PC8 + PC9 are on SiteA
PC6 + PC7 are on SiteB
i applied the above bridge filter rule on BOTH bridges; on SiteA as also on SiteB
now when i do a dhcp-release on the PCs (no matter on which) i see a dhcp req. popping up on both routers.
e.g.:
release of PC6 shows up on router SiteA and B
release of PC8 shows up on both routers too
same vor PC7 and PC9
please help … i’m completely new to EoIP and i’d love to have this solved 'cause EoIP would bring huge benefits for expanding my broadcast domains
yep, but if i did not get it wrong, EoIP is sort of exactly enable this feature?
so more helpful would be, if someone could sort the problem out to keep only DHCP requests of SiteA on SiteA and SiteB DHCP req. on SiteB…
I think before attempting something like connecting two existing networks using a bridge (like you are doing when
making an EoIP tunnel between them) you must first fully understand what that will do and what can go wrong.
Your current DHCP problem is just one example of this. There may be lots of other issues, depending on the use
and loading of the networks. You can of course apply filters to combat the problems one-by-one, but first you should
decide if you really want to do this and if a routed VPN isn’t a much better solution.
i do understand what it does and what indeed can go wrong …
this is more a lab setup and has more of a learning purpose concerning EoIP and how to (not) handle it (therefore it is virtualized in GNS3)
i also have many sites connected via OVPN and routed networks. all running fine and no problems here so far thanks
this setup is a test setup for maybe further implementation of tele-wokers.
the shall be connected via EoIP and their clients should then get the request from the DHCP server on the EoIP Target (the corporate network which the tele-worker is connected to)
for failover purposes there then may be a local DHCP on the tele-workers net
but this ist a rough draft yet … i would like to sort out the DHCP broadcasting obstacles first before i continue in further planning and testing of this EoIP solution…
btw:
the EoIP tunnel is realized via an OVPN tunnel between SiteA and SiteB if this info is any kind of vital (but i don’t think so - main target here is EoIP)
I agree with Pe1chl 100% - bridge over vpn over public Internet sounds like this should be a routed solution, not a bridged solution.
Are there reasons to bridge? Of course. But in general, bridging over WAN can lead to many more problems. I’ve personally responded to dozens of threads on here where the user was trying to work around some problem, but the problem was only there because their design was bad. It’s not that you CAN’T do some things, it’s more that “It’s not the best idea” to do that thing. (If a zookeeper posted to a zookeeper forum asking how to keep the alligators from eating the rabbits, the answer would be not to put the rabbits in with the alligators)
Split DHCP over a WAN that must otherwise be bridged is a tenuous solution. The problem being addressed is “I want to make sure that users at site A still get DHCP whenever the link to site B goes down.” Oh - and how do I keep users at site A from assigning static IP addresses from the range that is for site B? The simple answer is to make them independent networks and then route between them so that if the link is up, they can communicate. If it’s down, then they can’t. They both survive independently even if the link is down, though…
Okay - but for lab experimentation, anything goes, right? As stated earlier in the thread - a simple rule in the bridge at both sites will be fine - block in the forward chain, any udp whose destination port is 67 or 68 - you may even block source ports 67 or 68 as well, so in case a DHCP response is broadcast, that won’t get forwarded either.
If I do perform over-the-wan bridging, then one thing I do is make sure that the routers doing the bridging do NOT participate in the network themselves (so I would have different devices doing DHCP at the sites) - but that’s from a service provider’s point of view. The goal there is to hand off a port that looks and acts exactly like an unmanaged switch would do.
