I've spent all day trying to get this to work, and still struggling, even though its a simple task.

What I want is to use a public IP from my routed subnet directly on a server inside my network (without NAT). Current setup is:

The ISP provides the following over the connection (IP's changed):

Static IP: 1.1.1.1/30 with a default gateway of 1.1.1.2
Routed subnet: 2.2.2.1/28 (I want to use all 16 IP's so not setting the IP on any of my interfaces). ISP routes all IPs to the static IP above so should be ok.

So I have:
ether5 - connection to ISP. Static IP set to 1.1.1.1/30
ether9 - my server - IP: 2.2.2.1, subnet: 255.255.255.255, gw: 1.1.1.1

I have also added the following firewall rules:

add action=accept chain=forward dst-address=2.2.2.1 in-interface=ether5 out-interface=ether9
add action=accept chain=forward in-interface=ether9 out-interface=ether5 src-address=2.2.2.1

and a nat bypass:
add action=accept chain=srcnat src-address=62.252.149.9

I can't ping or get any connectivity from the server. This should be simple but it just isnt working

As a test, I assigned the 2.2.2.1 IP directly to the ether5 interface on the Mikrotik and I can ping it from an external site, so I know the routed subnet is reaching the router.

Any ideas?

Thank you

James

I believe the answers you seek are to be found here........
viewtopic.php?t=138896

I had a look at that along with many other posts but it wasn't clear of the final outcome and how it should be configured. Ideally I just want to map an IP from my routed subnet directly to a physical server plugged in to ether9 - no PPPoE in this case or NAT/IP tunnels. Is that possible?

Thanks

As indicated in that thread, just do this on router: And if you have server with 2.2.2.1/255.255.255.255 and gateway 1.1.1.1 connected to ether9, it will work. Well, if you don't block it with firewall or something.

Thanks. Even though I have 1.1.1.1 assigned as the ether5 static WAN IP already?

Thanks

Doesn't like it:

/ip address> add address=1.1.1.1/32 network=2.2.2.1/32 interface=ether9
invalid value for argument network

Doesn't like it:

/ip address> add address=1.1.1.1/32 network=2.2.2.1/32 interface=ether9
invalid 'sob" value for 'sniffle" argument network 'cries softly'[/b]

Fixed for dramatic and ironic affect!

Heh.

Managed to add it by removing the /32 from the network, so its just 2.2.2.1 but still not working.

The server at 2.2.2.1 plugged in to ether9 cant get any Internet. ping to 8.8.8.8 shows request timed out...

The torch tool shows a ping i am running to 2.1.1.1 (real ip 62.252.x.x in screenshot) from outside is being sent to ether9 and it appears it is responding but the ping fails, so, is it a firewall issue where traffic from ether9 cant go back out, like some nat or forward rule?

I enabled proxy-arp on ether9 and it now works. But should I need to do this? Is this strictly required? Does it introduce any issues?

Thanks

1) Using address=1.1.1.1/32 even though 1.1.1.1 is already on different interface should be ok. At least it was in previous RouterOS versions. I like this "recycling" to avoid having too many different addresses. But it's not required, you can use any other address, just pick something unique, e.g. some 10.x.x.x (and then use it also as gateway on server)
2) /32 in network=2.2.2.1/32 was my mistake, sorry.
3) You don't need proxy-arp. Try to change the address, as mentioned in 1).

Thanks

So without adding some dummy ip to the ether9 interface and then using this ip as the gateway on the server nothing would be routed, correct?

I tried what you said but it still doesnt work without enabling proxy arp on ether9.

Once I get this working, can I still use input firewall rules to block traffic to my server rather than all traffic hitting (as its passing through without nat etc)?

One thing to mention, if it matters, is that ether5 (wan) and ether9 are in different switch groups, so maybe why arp is required to get across the switches?

Thanks

James

Did you change settings on your server as well? The IP address/route config there should mirror the one from router ...

Indeed. With proxy-arp on its working, but without it's not. I'd like to avoid having to use proxy-arp if I can as it shouldn't be required I think?

Thanks

To double check, you have on router: and then on server, address = <srvaddr>, mask = 255.255.255.255, gateway = <gwaddr>, correct?

Maybe export and post the whole config, there's probably something unexpected in there.

Its working now - not sure why but ARP is just set to the default "enabled" instead of proxy-arp.

Sob and co, thanks for the help.

Last question - can I still limit the inbound traffic to the public IP using the MT firewall or is everything just "passed through" to the server now?

Thanks

James

Yes, "enabled" is the right value.

If you didn't change it, the two firewall rules from the first post allow everything from and to server. If that's not what you want, use different rules and allow only some ports as needed.

Strangely, in my testing, I removed those rules completely and the server still have access behind the assigned public IP, so seems it lets everything through. Guess I need to drop all and then allow just what I need through...

Weird as I thought it wouldn't work at all without the following:

add action=accept chain=forward dst-address=2.2.2.1 in-interface=ether5 out-interface=ether9
add action=accept chain=forward in-interface=ether9 out-interface=ether5 src-address=2.2.2.1

Thanks

James

Yep, I added a drop rule and then some specific forward rules for what I want open externally. Thanks!

Remember that firewall's default action is accept, everything you don't block is allowed.

Dunno if you solved this and I stand to be corrected but here's what I'm thinking:

You have 2 interfaces: eth5 and eth9. On eth5 you have 1.1.1.1 and on eth9 a server with 2.2.2.1 (with gateway 1.1.1.1) but no IP on the router ethernet interface.

This setup won't work because router has no IP connection on eth9 interface, so the router doesn't listen to IP traffic. You can't ping 1.1.1.1

Now you add 1.1.1.1 on eth9.

This time you can ping 1.1.1.1 but traffic isn't routed because router receives traffic on 1.1.1.1 but there are no routes setup from 1.1.1.1 to 0.0.0.0 via "the other 1.1.1.1".

However if you enable proxy-ARP the router replies to the server's "who has 1.1.1.1" with eth9's MAC address because it knows how to physically reach eth5, even though it's not on the same broadcast network.

The correct way to route IP traffic would be to add an IP address from the same subnet as the server to eth9, say 2.2.2.16, and set that as the gateway for that subnet. That way, the routing table in the router get's setup correctly and traffic that needs to get to 1.1.1.1 get's routed via 2.2.2.16.

The proxy-ARP solution should work fine though and aside from a bit higher CPU load due to processing some extra layer 2 traffic, and not being aple to apply some layer 3 filtering, I don't think their should be any downsides.

Putting the whole subnet on internal interface is the most simple and compatible way. Problem is that by doing so, you throw three addresses out of window (network address, broadcast, gateway address). So instead of 16 usable addresses (for /28), you have only 13. And on top of that, you're limited where you can connect your devices, even though you can get around it using some tricks like proxy arp. If you use point-to-point /32 addresses, you can have all 16 and route them freely anywhere you want. If your device supports it, there's nothing wrong with it.

The only questionable part could be the "address recycling", when there are more than one 1.1.1.1. This is definitely not required, so simply choose some other unique address, it will work too and it's clean config.

Whether having more than one 1.1.1.1 is wrong, that's a question. RouterOS doesn't mind (same is true for Linux). And as long as there are no overlapping subnets, I haven't seen any unwanted side effects. Nothing behaves as if there was "first 1.1.1.1" and "other 1.1.1.1" (and possibly more), it's just one 1.1.1.1.

Great explanations guys. Really appreciate the informative replies.

James