hi everyone … I have a CHR certified in a data center with a public / 29 assigned … the same CHR has statically assigned only one public ip, I would need to bring four of these public ip’s to a remote location … a gre between the main CHR and a secondary one and carry more public IPs, then in the secondary router put the gre interface in a bridge in order to assign the other three ip’s to the VMs under a server … the doubt is that I don’t know if it is the correct way to do it … I accept advice or / and indications about it ..
Do I get you right that the CHR’s own WAN address is from that /29 on the WAN of the CHR in the data center, i.e. you have to spend three more IP addresses for the gateway, network, and broadcast, and the CHR must respond also to ARP requests for the remaining four addresses? Or is that /29 routed to the CHR by means of some other address?
the addresses 1.1.1.1/29 come from the datacenter, the CHR1 ISP is a 1.1.1.1/32 ip of the famous pool to be transported to the other side .. I have updated the drawing so maybe you understand better
I don’t think you understood. What does CHR1 use as gateway? Is it address from this /29?
Yes
the gateway of chr1 is 1.1.1.6
OK.
So first, if you want to avoid issues with MTU as much as possible, use L2TP with MLPPP enabled to interconnect the two rather any other type of tunnel. Let’s suppose the server side will be the CHR 1, so make a static reservation for the tunnel interface (a link between the user name and the interface name), such as l2tp-chr2. Use any non-conflicting private address for local-address for that client, and 1.1.1.2 as the remote-address.
Second, you’ll have to add one route per each of the three 1.1.1.x addresses with that tunnel interface as a gateway.
Then, create arp records for those three addresses and also for 1.1.1.2 at the WAN interace, with publish=yes (no need to specify MAC address for these records).
That’s all at CHR 1 regarding routing, but you probably want to use some specific firewall rules for these addresses.
On CHR 2, acting as the L2TP client, it should be possible to configure the uplink interfaces of the three VMs as Ethernet point-to-point links, probably best to put each to its own VLAN at the vswitch of the virtualization host. I.e. they would have 1.1.1.x/32 at their own end and a non-conflicting private address at the CHR end. So at the Mikrotik, you would set three /interface vlan named e.g. vm-1, vm-2, vm-3, and set the addresses the following way:
/ip address
add address=10.11.12.13/32 network=1.1.1.3 interface=vm-1
add address=10.11.12.13/32 network=1.1.1.4 interface=vm-2
add address=10.11.12.13/32 network=1.1.1.5 interface=vm-3
Last thing regarding routing is to add a routing table via-chr1, consisting of a single default route, and a routing rule saying when to use it:
/ip route
add routing-mark=via-chr1 gateway=l2tp-out-chr2
/ip route rule
add src-address=1.1.1.0/29 action=lookup-only-on-table table=l2tp-out-chr2
But also here you may want some specific firewall rules.
your solution seems concrete, I did not understand in this step where you add them addresses because this ip 10.11.12.13/32 .. you could be more specific … also maybe, correct me if I say bullshit, the ip 1.1.1.0/29 you specify in the ip route rule shouldn’t they be all but 1.1.1.1 and 1.1.1.6? because if you confirm this rule I could do it in mangle using an address list
Take a look at this post, it might help http://forum.mikrotik.com/t/routing-a-block-of-public-ip-addresses-to-other-mikrotik/138145/1
If you want exactly what you have in image, you’d use this instead of VLANs and those 10.11.12.13/32 addresses:
/ip route
add dst-address=1.1.1.3 gateway=10.10.10.2
add dst-address=1.1.1.4 gateway=10.10.10.2
add dst-address=1.1.1.5 gateway=10.10.10.2
Server would then have to take care of routing it further to VMs.
The important part is config of CHR1 and tunnel. Then on CHR2 you have traffic to 1.1.1.3-5 coming from tunnel, and it’s up to you what you do with it.
The address 10.11.12.13/32 is just an example of some non-conflicting private IP address - it is actually only used because on some operating systems you cannot use an interface name as a gateway, so you have to specify it as an IP address. And you need that Mikrotik answered ARP requests for this address.
As for the 1.1.1.0/29 - the thing is that neither 1.1.1.1 nor 1.1.1.6 will ever appear as source addresses at CHR-2, except the transport packets of the tunnel that are, however, not forwarded by CHR 2, and therefore CHR 2 does not route them, so the /ip route rule doesn’t affect themïr handling. So a single route rule is sufficient, instead of four that would be needed for /32 addresses.
If you already use mangle rules at CHR 2 anyway, you can use them also for this purpose, the amount of extra CPU spent should be negligible. But as you haven’t provided the current configuration of either CHR, I gave you the solution which is most efficient.
I suspect the “server” is a virtualization environment like VMware or Hyper-V, i.e. not a router. And even if it was a router, there’s still the issue that it would have to replicate the /29 locally, which I admit is not such a big deal but it would make the setup even mor confusing.
@sindy: About the routing rule, I was actually curious how are you going to handle it. With src-address=1.1.1.0/29, how about CHRs 1.1.1.1-2 trying to communicate with 1.1.1.3-5? It shouldn’t work. But when I tested it just to be sure, it behaved weirdly. I could ping 1.1.1.3 from CHR2 if I didn’t specify source address (slighly unexpected). But it didn’t work when I used ping with src-address=1.1.1.2 (expected; it was routed to CHR1). But logging in output showed 1.1.1.2 as source for both (???). Another rule to look up destination 1.1.1.3 only in main routing table (to find connected route) fixed ping, but then ssh complained about no route to destination. I feel like I must have overlooked something.
I’ve intentionally neglected the communication between the virtual machines and the CHRs, that’s all.
So yes, if you wanted that, you’d need additional rules, exempting VM’s traffic towards CHR 2 as well as CHR 2’s traffic towards the VMs from the /29 rule. So just four rules with /32 src-addresses instead of a single one with a /29 src-address would not be sufficient anyway. And you would need another rule to exempt traffic from CHR 1 to anything else than CHR 2 itself from being sent back to CHR 1.
As for the unexpected behaviour you’ve seen, I don’t have an explanation for most of it either. It is normal that you can ping 1.1.1.3 from CHR 2 if the address at the CHR 2 end of the PtP Ethernet link betwen them is not 1.1.1.2, but it is indeed strange that the address shown by the sniffer was 1.1.1.2 in this case. Why ssh should behave different from ping is also unclear to me.
tomorrow morning I do all the necessary tests … excuse the question, at the beginning of the question you asked me if the gateway of the chr was present in the pool 1.1.1.0/29 if it were not, and maybe the gateway was a private ip, what would change?
If you’d have the whole subnet routed to CHR1 (i.e. CHR1 would have 5.5.5.2/30 and ISP would add route to 1.1.1.0/29 via 5.5.5.2), you’d have slightly more freedom, you could route the whole thing further to CHR2 and either assign it there as regular subnet, or you could use all eight addresses individually.
I did some quick tests and it seems to work..but I don’t have the server, it arrives Monday … if I put a mikrotik with private ip 10.200.1.2/30 in place of the server and I bridge with ether1 and ether3, on ether3 I connect another router (to simulate vm1) by assigning public ip to the router that simulates vm1 which network and which gateway should I set? post the image of the final configuration so you tell me if I understand all the concepts said correctly
I’m not sure about the add-default-route=yes for the L2TP client at CHR 2 - do you indeed want to use 2.2.2.2 only to set up the tunnel towards CHR 1 but all traffic of whatever is behind CHR 2 should go to the internet via CHR 1? If so, you don’t need the additional routing table and routing rules at CHR 2 at all, but you need a route to 1.1.1.1 via the 2.2.2.2’s gateway instead, otherwise the L2TP transport packets would become L2TP payload and get nowhere.
let’s say that I put add default route to simplify the tests, in fact being the default route in this case the routes do not make sense, but I will try to change this … on chr there is no traffic except the transit itself of the ip 1.3 1.4 and 1.5..modifying the routing table as you said, then making a routing Mark and letting out with l2tp only 1.1.1.0/29, to the question above, the vm with public ip? Which gateway should it call?
One more time - you can get rid of the via-chr1 routing table completely and let the L2TP tunnel be the defaul gateway of the CHR, but if you do, you must provide a route to 1.1.1.1 via 2.2.2.2’s gateway in the main routing table to allow the L2TP tunnel to work.
For the “VM”, the default gateway will be the IP addres of CHR 2 specified as the “address” on the Ethernet point to point link. This will make it send all its traffic to CHR 2, and CHR 2 will use its own routing to do the rest.
What virtualisation platform are you going to use on the server?