Hi All

I have a set up where I have two sites linked via RB750G routers over IPSEC tunnel. I want site B to get its DHCP from a DHCP server in site A. I have set up the relay, etc, but there is an issue getting the routers to traverse the tunnel correctly. Devices behind the router are fine as they follow the prerouting -> forward -> postrouting rules, whereas traffic originating inside the router use output -> postrouting. As the device originates inside the router, it sets the source address to be the public IP of the router which means it needs special NAT rules to handle this condition.

I tried putting in a source nat rule that says if the source is <my external IP> and the dest is <the lan IP of the remote router>, src nat to <the LAN IP of my router>. This works sometimes, but not consistently. Is there a best practise method to get a Microtik router to traverse the IPSEC reliably?

Regards

Mark Dutton

What you're doing is essentially changing packet headers so that they match the IPsec policy. That works and should work consistently, you just have to be careful to never touch the encrypted packets (which will also go through output and postrouting). Alternatively you could add more policies so that the unchanged packets match and will be encrypted on merit of just their original headers.

OK, that makes sense. Could you please in basic ascii art, show the path the packets take including encryption. I am used to Linux IP using freeswan, which encrypts data before it enters the routing stack. I can see the advantages of encypting after routing, particularly when doing QoS, but I am a bit unsure of how it works. I thought it was like this.

PREROUTING--->FORWARD--->POSTROUTING--->ENCRYPT---->EGRESS for traffic from devices behind the router
OUTPUT--->POSTROUTING--->ENCRYPT--->EGRESS FOR traffic from the router

Do I have this right?

http://wiki.mikrotik.com/wiki/Manual:Packet_Flow
No need to ASCII art.

Excellent diagrams! I actually saw these previously, but I did not scroll down to the end, which shows clearly the double handling of packets through the output routing phase if encrypted. This leads me to two more questions.

1. Will packet marks survive the encryption process?
2. Related to above, if I want packets going through an IPSEC tunnel to be QoS prioritised through rules relating to the traffic type within the tunnel, what is the best way to do this? I am guessing I mark the packets at prerouting phase using mangle (I do this now), then when they go through the IPSEC and round a second time, eventually hitting the HTB, the packet marks (if still on the packets) will put the traffic into the correct queue. Is this correct, or do I need to do something else to ensure my IPSEC packets are marked correctly based on their contents inside the tunnel and not the IPSEC packets themselves?

1. No, they will not. The encrypted packets are completely separate, and also a different connection.
2. As far as I know you cannot. There is no way to refer back to the original packet. All you can do is mark the now encrypted packets in postrouting or output and prioritize all IPSec (or any subsection of IPSec traffic as available by the facilities, but not based on the encrypted content).

That's to the best of my knowledge. I can't say I've extensively played with IPSec on RouterOS. Other routers let you carry over DSCP marks from the plain to the encrypted packet but RouterOS doesn't seem to have that option.

That's right. On a standard Linux router using the Freeswan IPSEC stack we would set a flag in the ipsec.conf file being hidetos=no. This would cause the encrypter to put the DSCP flag into the outer packet.

We would then create a mangle rule as follows.

iptables -t mangle -I TS -p 50 -j RETURN
iptables -t mangle -I TS -p udp --dport 4500 -j RETURN

before the QoS policy markings which ensures that any QoS policies are not processed on these packets.

Having said all this, I have configured a queue tree on my WAN port and I am definately seeing VOIP traffic that is headed through IPSEC appearing in the correct queue. This would indicate that perhaps the encrypter DOES preserve the tunneled packet QOS bits, which is great.

It would be great if you could determine definitively if it does and post that to the forums.
It sort of sounds like it does preserve those headers but doesn't give you an option for it.

As I have mentioned many many times before, It would be nice if RouterOS supported VTI (virtual tunnel interfaces) in their IPSEC implementation. This would allow you to simply add a route via the VTI, then all traffic destined to that destination would be sent via the IPSEC tunnel. This makes DHCP relay over IPSEC easy, as well as allowing OSPF over IPSEC without having to use hideous GRE/EoIP tunnelling.

Circa 2001 Netscreen's supported this, Cisco 877's supported this, FortiGate's support it, JunOS supports it, please please add it to RouterOS.

OK. I believe it is definately preserving the markings on encryption. here is what I do.

in prerouting mangle table, I mark the packets based on DSCP, address:port, whatever as VOIP.

I then create a queue tree with a queue dedicated to VOIP. The queue tree is attached to my external interface.

My SIP proxy is on the other end of my IPSEC tunnel. It is also an RTP proxy, so ALL traffic from the phone goes through my IP PBX on the other end of the IPSEC tunnel.

When I am on a call I see the traffic in my VOIP queue.

It seems that the default behaviour is to honour markings of the traffic in the tunnel after encryption. There does not seem to be any way to stop this and I think there should be, but if you had to pick one option, I believe the engineers picked the right one.

I agree with nz_monkey re: the VTI interface. This thread started because I had such a tough time trying to get traffic through the tunnel from the router itself. Not too keen to use GRE, or EOIP. If I can get the NAT rules to be reliable, I would prefer that. Meanwhile I have given up trying to do DHCP relay for now.